nodev proc
nodev sockfs
nodev tmpfs
nodev shm
nodev pipefs
ext2
nodev ramfs
iso9660
nodev devpts
ext3
nodev usbdevfs
nodev usbfs
ReiserFS
vfat
nodev nfs
nodev autofs
nodev binfmt_misc
The entries not preceded by nodev are not of interest to us because they do not provide any information about the file system. On this machine, the ext2, ext3, vfat, reiserfs, and iso9660 file systems are supported. Modules for other file systems could be loaded if needed.
Working with the ext3 File System
Red 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 Mandriva, 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. All the ext2 tools provided by Fedora 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, is completely compatible with ext2.
Understanding the ext3 File System Structure
Fedora'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 made 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.
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.
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, 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 ext3
The ext3 file system has several options that, depending on your needs, allow you to select how much information is journaled. Generally speaking, 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
