Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

Listing 9-3 displays the directory contents of a Flash device configured for an arbitrary embedded system.

Listing 9-3. Flash Device Listing

$ ls -l /mnt/flash

total 24

drwxr-xr-x 2 root root 1024 Jul 18 20:18 bin

drwxr-xr-x 2 root root 1024 Jul 18 20:18 boot

drwxr-xr-x 2 root root 1024 Jul 18 20:18 dev

drwxr-xr-x 2 root root 1024 Jul 18 20:18 etc

drwxr-xr-x 2 root root 1024 Jul 18 20:18 home

drwxr-xr-x 2 root root 1024 Jul 18 20:18 lib

drwx------ 2 root root 12288 Jul 17 13:02 lost+found

drwxr-xr-x 2 root root 1024 Jul 18 20:18 proc

drwxr-xr-x 2 root root 1024 Jul 18 20:18 root

drwxr-xr-x 2 root root 1024 Jul 18 20:18 sbin

drwxr-xr-x 2 root root 1024 Jul 18 20:18 tmp

drwxr-xr-x 2 root root 1024 Jul 18 20:18 usr

drwxr-xr-x 2 root root 1024 Jul 18 20:18 var

$

Listing 9-3 is an example of what an embedded systems root file system might look like at the top (root) level. Chapter 6, "System Initialization," provides guidance and examples for how to determine the contents of the root file system.

The e2fsck command is used to check the integrity of an ext2 file system. A file system can become corrupted for several reasons, but by far the most common reason is an unexpected power failure or intentional power-down without first closing all open files and unmounting the file systems. Linux distributions perform these operations during the shutdown sequence (assuming an orderly shutdown of the system). However, when we are dealing with embedded systems, unexpected power-downs are common, and we need to provide some defensive measures against these cases. e2fsck is our first line of defense for unexpected power-down using the ext2 file system.

Listing 9.4 shows the output of e2fsck run on our CompactFlash from the previous examples. It has been formatted and properly unmounted; there should be no errors.

Listing 9-4. Clean File System Check

# e2fsck /dev/sdb1

e2fsck 1.37 (21-Mar-2005)

CFlash_Boot_Vol: clean, 23/2880 files, 483/11504 blocks

#

The e2fsck utility checks several aspects of the file system for consistency. If no issues are found, e2fsck issues a message similar to that shown in Listing 9-4. Note that e2fsck should be run only on an unmounted file system. Although it is possible to run it on a mounted file system, doing so can cause significant damage to internal file system structures on the disk or Flash device.

To create a more interesting example, Listing 9-5 was created by pulling the CompactFlash device out of its socket while still mounted. We intentionally created a file and editing session on that file before removing it from the system. This can result in corruption of the data structures describing the file, as well as the actual data blocks containing the file's data.

Listing 9-5. Corrupted File System Check

# e2fsck -y /dev/sdb1

e2fsck 1.37 (21-Mar-2005)

/dev/sdb1 was not cleanly unmounted, check forced.

Pass 1: Checking inodes, blocks, and sizes

Inode 13, i_blocks is 16, should be 8. Fix? yes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb1: 25/2880 files (4.0% non-contiguous), 488/11504 blocks

#

From Listing 9-5, you can see that e2fsck detected that the CompactFlash was not cleanly unmounted. Furthermore, you can see the processing on the file system during e2fsck checking. The e2fsck utility makes five passes over the file system, checking various elements of the internal file system's data structures. An error associated with a file, identified by inode [71] A file on a file system is represented by an internal ext2 data structure called an inode. 13, was automatically fixed because the -y flag was included on the e2fsck command line.

Of course, in a real system, you might not be this lucky. Some types of file system errors are not repairable using e2fsck. Moreover, the embedded system designer should understand that if power has been removed without proper shutdown, the boot cycle can be delayed by the length of time it takes to scan your boot device and repair any errors. Indeed, if these errors are not repairable, the system boot is halted and manual intervention is indicated. Furthermore, it should be noted that if your file system is large, the file system check (fsck) can take minutes or even hours for large multigigabyte file systems.

Another defense against file system corruption is to ensure that writes are committed to disk immediately when written. The sync utility can be used to force all queued I/O requests to be committed to their respective devices. One strategy to minimize the window of vulnerability for data corruption from unexpected power loss or drive failure is to issue the sync command after every file write or strategically as needed by your application requirements. The trade-off here is, of course, a performance penalty. Deferring disk writes is a performance optimization used in all modern operating systems. Using sync effectively defeats this optimization.

The ext2 file system has matured as a fast, efficient, and robust file system for Linux systems. However, if you need the additional reliability of a journaling file system, or if boot time after unclean shutdown is an issue in your design, you should consider the ext3 file system.

The ext3 file system has become a powerful, high-performance, and robust journaling file system. It is currently the default file system for many popular desktop Linux distributions such as Red Hat and the Fedora Core series.

The ext3 file system is basically an extension of the ext2 file system with added journaling capability. Journaling is a technique in which each change to the file system is logged in a special file so that recovery is possible from known journaling points. One of the primary advantages of the ext3 file system is its capability to be mounted directly after an unclean shutdown. As stated in the previous section, when a system shuts down unexpectedly, such as during a power failure, the system forces a file system consistency check, which can be a lengthy operation. With ext3 file systems, there is no need for a consistency check because the journal can simply be played back to ensure consistency of the file system.

Without going into design details that are beyond the scope of this book, it is worth a quick explanation of how a journaling file system works. A journaling file system contains a special file, often hidden from the user, that is used to store file system metadata [72] Metadata is data about the file, as opposed to the file's data itself. Examples include a file's date, time, size, blocks used, and so on. and file data itself. This special file is referred to as the journal. Whenever the file system is subject to a change (such as a write operation) the changes are first written to the journal. The file system drivers make sure that this write is committed to the journal before the actual changes are posted and committed to the storage media (disk or Flash, for example). After the changes have been logged in the journal, the driver posts the changes to the actual file and metadata on the media. If a power failure occurs during the media write and a reboot occurs, all that is necessary to restore consistency to the file system is to replay the changes in the journal.