Section 9.2. ext2

9.2. ext2

Building on the example of Listing 9-1, we need to format the partitions created with fdisk. To do so, we use the Linux mke2fs utility. mke2fs is similar to the familiar DOS format command. This utility makes a file system of type ext2 on the specified partition. mke2fs is specific to the ext2 file system; other file systems have their own versions of these utilities. Listing 9-2 captures the output of this process.

Listing 9-2. Formatting a Partition Using mke2fs

# mke2fs /dev/sdb1 -L CFlash_Boot_Vol mke2fs 1.37 (21-Mar-2005) Filesystem label=CFlash_Boot_Vol OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 2880 inodes, 11504 blocks 575 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=11796480 2 block groups 8192 blocks per group, 8192 fragments per group 1440 inodes per group Superblock backups stored on blocks:          8193 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 39 mounts or 180 days, whichever comes first.  Use tune2fs -c or -i to override. # 

Listing 9-2 contains a great deal of detail relating to the ext2 file system and provides an excellent way to begin to understand its operational characteristics. Note that this partition was formatted as type ext2 with a volume label of CFlash_Boot_Vol. It was created on a Linux partition (OS Type:) with a block size of 1024 bytes. Space was allocated for 2,880 inodes, occupying 11,504 blocks. An inode is the fundamental data structure representing a single file. For more detailed information about the internal structure of the ext2 file system, the reader is directed to Section 9.11.1 at the end of this chapter.

Looking at the output of mke2fs in Listing 9-2, we can ascertain certain characteristics of how the storage device is organized. We already know that the block size is 1024 bytes. If necessary for your particular application, mke2fs can be instructed to format an ext2 file system with different block sizes. Current implementations allow block sizes of 1,024, 2,048, and 4,096 blocks.

Block size is always a compromise for best performance. On one hand, large block sizes waste more space on disks with many files because each file must fit into an integral number of blocks. Any leftover fragment above block_size * n must occupy another full block, even if only 1 byte. On the other hand, very small block sizes increase the file system overhead of managing the metadata that describes the block-to-file mapping. Benchmark testing on your particular hardware implementation is the only way to be sure you have selected an optimum block size.

9.2.1. Mounting a File System

After a file system has been created, we can mount that file system on a running Linux system, provided that we have access to the hardware device and that the kernel has been compiled with support for our particular file system type, either as a compiled-in module or a dynamically loadable module. The following command mounts the previously created ext2 file system on a mount point that we specify:

# mount /dev/sdb1 /mnt/flash

This example assumes that we have a directory created on our target Linux machine called /mnt/flash. This is called the mount point because we are installing (mounting) the file system rooted at this point in our file system hierarchy. We are mounting the Flash device described earlier that the kernel assigned to the device /dev/sdb1. On a typical Linux desktop (development) machine, we need to have root privileges to execute this command.^[2] The mount point is any place on your file system that you decide, which becomes the top level (root) of your newly mounted device. In the previous example, to reference any files on your Flash device, you must prefix the path with /mnt/flash.

^[2] File systems can be made mountable by nonroot users, as with cdrom.

The mount command is a powerful command, with many options. Many of the options that mount accepts depend on the target file system type of the mount operation. Most of the time, mount can determine the type of file system on a properly formatted file system known to the kernel. We provide additional usage examples for the mount command as we proceed through this chapter.

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.

9.2.2. Checking File System Integrity

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 ^[3] 13, was automatically fixed because the -y flag was included on the e2fsck command line.

^[3] A file on a file system is represented by an internal ext2 data structure called an inode.

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.