Working with the ext3 File System
Working with the ext3 File SystemRed Hat had invested heavily in the development of the ext3 file system and provides support for the ext3 file system as the journaling file system for its distribution. Red Hat (and now Fedora) does not provide that level of support for other file systems. Other distributions, such as SuSE and Mandrake, support the Reiser file system, which is covered later. The ext3 file system is an update to the ext2 file system, which has been one of the most popular Linux file systems for some time. You can choose to use the ext3 file system during a fresh install or automatically convert to an ext3 file system when you upgrade your present system to the current version of Fedora Core Linux. All the ext2 tools provided by Fedora Core have been upgraded to work with both ext2 and ext3. We mention the ext2 tools only because you will see the ext2 file system mentioned frequently; ext3, as supplied with Fedora Core Linux, is completely compatible with ext2. Understanding the ext3 File System StructureFedora's rationale for choosing ext3 might be compelling. Although it provides availability, data integrity, and speed similar to other file system choices, ext3 has one unique advantage: It is an easy transition from ext2 to ext3, and the transition is forgiving of mistakes along the way. It is also potentially possible to recover a deleted file from an ext3 file system; such a recovery is not possible at all for a reiserfs file system. Note The downside to using ext3 seems to be performance related. A recent benchmarking evaluation (see http://fsbench.netnation.com/) of all Linux file systems placed ext3 at the bottom for general performance. What the study really demonstrates is that you must match the file system to the application for best all-around performance. The ext3 file system can accommodate files as large as 2TB, directories as large as 2TB, and a maximum filename length of 255 characters. (With special kernel patches, this limit can be increased to 1,024 characters if the standard length is insufficient for your use.) The ext3 file system can allocate and use empty space in a very efficient manner. The usage of space is so efficient that ext3 file systems typically do not need defragmenting (rearranging the files to make them contiguous). The dynamic allocation of resources is also the source of one Achilles heel for the file system. When a file is deleted, its inode is erased and the data blocks associated with it are freed; they might very well be reallocated immediately, and the old data lost forever. Note A defragmentation program for the ext2 file system does exist, but it is infrequently used, is not typically included with standard Linux distributions such as Fedora Core Linux, and is not recommended for general use. The ext2/3 file system assigns blocks of space for files based on their parent directories; this spaces files out all over the physical disk, leaving room to keep files contiguous and reduce fragmentation. However, a file system full of files at 90% of its capacity can become badly fragmented. Every file system varies in structure, depending on its efficiency, security, and even proprietary designs to limit cross-compatibility deliberately. The ext3 file systems were designed to follow UNIX design concepts, particularly "everything is a file." For example, a directory in the ext3 file system is simply a file; that file contains the names of the files to be found in that directory, and the locations of those files. The list of names is linked so that space is not wasted because of varying filename lengths. Journaling Options in ext3The ext3 file system has several options that, depending on your needs, allow you to select how much information is journaled. According to Red Hat, the typical journal requires a second or so to be read and recovered. The time needed to recover from an improper shutdown of a journaled file system is not dependent on the file system size, but the amount of data in the journal. The default setting provided by Fedora is adequate for most needs. The optimal choice depends on so many factors (computer usage, hardware used, and testing and evaluation methods) that a meaningful discussion is beyond the scope of this chapter. You learn in this chapter what the choices are and how they differ, but whether a choice is right for you can only be determined on an individual basis. Like all journaling file systems, the traditional file system check (fsck) is not necessary on an ext3 file system. Although only mildly annoying on a 20GB drive on your machine at home, imagine the seemingly endless hours that an fsck would take to run on a terabyte of data. This feature is shared in common with the other journaling file systems. When choosing journaling options, you can trade off data integrity (keeping your data current and valid) for data transfer speed in your file system's operation; you cannot have both because of the nature of the file system design. You can choose to expose some of your data to potential damage in the case of an improper shutdown in exchange for faster data handling, or you can sacrifice some speed to keep the state of the file system consistent with the state of the operating system. Three modes available as options to ext3 are as follows:
For most of us, the default selection represents a good trade-off. Fedora Core supports booting from an ext3 formatted root file system with the proper drivers loaded in the initrd image. The mode is selected by using the appropriate mount option in /etc/fstab. For example, to set the file system mode to the fastest of the three modes, use data=writeback as the option. For more details, enter man mount. Verifying File Integrity in ext3 File Systems with the fsck UtilityThe file system integrity is assured using fsck, or file system check, programone of five commands in the library that are used to maintain and modify the ext3 file system. When fsck is run, it performs a sequential analysis of the file system information available in the file system if it detects a directory that cannot be traced back to the root or an undeleted file with a zero link count. It places these directories and files in the /lost+found directory that is created on each physical partition by the file system formatting process. Some blocks are reserved for this and other uses of the super-user. It is possible to reduce this allocation to free additional space for regular users by special arguments to the formatting program mke2fs. To run the fsck command, use the name of the file system as the argument. You must ensure that the file system you want to check is unmounted by using the umount command. If you want to fsck the file system at /dev/hdc, for example, do this: # fsck /dev/hdc Tip If you are logged on as a regular user and su to root using su, you do not inherit root's environment and path, meaning that the preceding command will not work without using the full path: /usr/sbin/fsck. Either type the full path each time, or become root with su -, which causes you to inherit root's environment and path; you have less to type. The file system state is tracked in the ext3 file systems. A special field in the superblock tells the kernel that, after the file system is mounted read/write, it is marked as not clean; when it is properly unmounted, it is marked as clean. If a file system is not unmounted properly, it could contain corrupt data because all the file data might not have been written to it. (This is what the journaling file systems such as ext3 strive to eliminate.) When the system is booted, this flag is checked and if it is not clean, the program fsck is run. Internally, fsck is actually a wrapper program that runs the appropriate version of fsck for the file system in use: fsck.minix, fsck.ext2, fsck.ext3, fsck.reiserfs, fsck.msdos, and fsck.vfat. If the kernel detects an inconsistency in the superblock field, the file system is marked erroneous, and the file system check is forced even if other indicators suggest that fsck does not need to be run. By default, the system will run fsck on a file system after a periodic number of reboots, regardless of the status of the clean flag. This behavior is triggered by a mount counter kept in the superblock or after a predetermined amount of time has elapsed since the last reboot (information also kept in the superblock). These parameters can be adjusted through the tune2fs command; this command can also be used to modify how the kernel handles the erroneous flag and, interestingly, the number of blocks reserved for the super-user, also known as root. This latter option is useful on very large or very small disks to make more disk space available to the user. |
EAN: 2147483647
Pages: 362