මෙම පිටුව යාවත්කාලීන කරමින් පවතී...
Any embedded system is subjected to unexpected power failures. For some system, it may happened when user pull the plug instead of shutting down. For others, this only occurs when the power source goes down. Suppose that if it is an automotive system, It anticipated that sudden power start and stop several times per day. If this embedded system is implemented, Without thinking about what happens when the power goes down, it could lead to catastrophic failures down the road. Unexpected power failuer may caused to damage the boot medium( especially rootfs) if it is occured when the file is written.
- Solution 1 : Format the rootfs using a journaling file system such like ext3/ext4 or btrfs. This kind of filesystem keep the backup of file that going be updated and delete the journal log after comitting the file. When the system is booting, checks the journal log and recover the file if it's uncommited. This solution is not 100% reliable. There may be a prosibility to rootfs corruption.
- Solution 2 : Using NAND Flash memeory insted of Maganatic HDD. When a NAND write from the filesystem occurs, it must write a page at a time, and it must be erased before writing. However, in order to erase a page you must erase an entire block which will include many pages. As an example from a Micron NAND, a page is 4KiB, and the erase block is 1MiB. A filesystem or FTL (Flash Translation Layer) will store multiple files within a block, so if power is lost during an erase/write it is possible to lose the entire block and the multiple files stored on them.
With an understanding of the NAND flash implementation being used in your embedded system there are several ways to protect against filesystem corruption in embedded Linux. Most popular way is use a union/read-only file system.
Understand what a Read-Only Root Filesystem/Union Filesystem
Files that don’t need to be modified should be kept on a partition that is mounted read-only. If all writes are avoided then there is no risk of a write being interrupted and corrupting the disk. Besides, It reduces the read/write cycle with the memory card, and gives long-life to CD card.
How it works?
While keeping their actual contents separate, union file systems are allowed a virtual merge of multiple folders, It is more of a mounting mechanism than a file system.
The technique is shown in the graphic below, it involves two directories, each containing files and folders. Suppose them as upper layer and lower layer. The lower layer is read-only. File access through the OverlayFS retrieves data from the upper directory first, and then defaults to the lower directory if a file doesn’t exist. Note that the two original upper and lower directories are still directly accessible to the Linux kernel, but this access could be limited by the application.
Modifications to files in the upper directory will occur as usual. Any modification to a file from the lower folder will create a copy in the upper, and that file will be the one modified. This leaves the base files untouched and available through direct access to the lower folder.
A second task could copy modified files from the upper folder to the lower when modifications are complete. In this way, an OverlayFS setup could simulate some of the functionality of transaction points within the Reliance Nitro file system.
A file removed from the OverlayFS directory would directly remove a file from the upper directory, and simulate that removal from the lower directory by creating a “whiteout” file. This file exists only within the OverlayFS directory, without physically appearing in either the upper or lower directories. When the OverlayFS is dismounted, this state information will be lost, so care should be taken to reflect any necessary changes to the lower directory.
A subdirectory can also be deleted from the lower directory, which creates an “opaque” directory in the OverlayFS directory. Behind the scenes, OverlayFS uses the “trusted” extended attribute class or namespace to record whiteouts and opaque directories. Linux file systems that support the trusted namespace can be used for either, and Reliance Nitro is among that set.