- More Filesystems than You Can Shake a Memory Stick at
- ext3: Backward-Compatible, Upwardly Mobile
- JFS: IBM Really, Really Supports Linux
- ReiserFS: A Pioneering Mobile Target
- XFS: User-Tested, Mother Approved
- Summary
ext3: Backward-Compatible, Upwardly Mobile
The primary concern when adding a new type of filesystem to your computer system and committing actual user data to that filesystem is its reliability. Linux systems provide an intermediate kernel interface for filesystems, called the Virtual Filesystem Switch (VFS), which makes it relatively easy to add a new type of filesystem to existing computer systems by simply plugging it in. However, even for the best developers, the huge amount of new code beneath this layer is a sea in which potential problems may lurk.
The ext3 filesystem development team took a unique approach to creating a new type of journaling filesystem. As mentioned in the first article in this series, the ext2 filesystem is the canonical Linux filesystem. Because the ext2 filesystem is well-understood, stable, and thoroughly trusted by anyone who has ever saved data on a Linux system, the developers of the ext3 filesystem decided that the easiest way to add a journaling filesystem to Linux was to add journaling capabilities to the ext2 filesystem. This lets the ext3 filesystem leverage the years of development and testing that went into the development of the ext2 filesystem; lets ext3 continue to use the excellent utilities that have been developed to analyze, repair, and fine-tune ext2 filesystems; and lets the ext3 filesystem instantly take advantage of any improvements, enhancements, and fixes made to the existing ext2 filesystem.
The ext3 journaling filesystem is structurally identical to the standard Linux ext2 filesystem, with the exception of the file necessary to contain the journal itself. Obviously, the internals of every filesystem update operation are different to actually do journaling, but the physical layout of the filesystem on disk is identical between the two. The inode and related filesystem data structures used in the ext3 filesystem are the same as those in the ext2 filesystem. The fact that the ext3 filesystem is 100 percent-compatible with the existing ext2 filesystem makes it possible to convert existing ext2 filesystems to ext3 without reformatting the partition or logical volume on which an existing ext2 filesystem is located. This totally eliminates the need to migrate data between the two—it's already there.
The ext3 filesystem is largely implemented through a journaling layer written by the ext3 team and implemented as a standalone subsystem in the Linux kernel. This journaling subsystem is known as JBD, which stands for journaling block device subsystem. (It was originally known as the journaling file subsystem, or JFS, which tended to generate more confusion than anything else due to other uses of the acronym, one of which I'll discuss later.)
The ext3 JBD subsystem provides transactional logging similar to that originally developed for use by databases. As used by the ext3 filesystem, you can specify whether you want to log all changes to both file data and metadata, or whether you simply want to log metadata changes. Regardless of which of these you select, the ext3 JBD subsystem guarantees the atomicity of the changes associated with a specific filesystem update. It does this by stamping all log records with an identifier for the transaction with which they are associated and by using specific types of log records that indicate that a transaction has been committed.
The ext3 filesystem and the JBD subsystem that it uses are sophisticated, well-designed additions to the core feature set of modern versions of Linux. Not only is ext3 robust, but it depends on an existing, robust code-base; and eliminates any of the hassles inherent in migrating data between different types of filesystems. Built-in support for the ext3 filesystem is provided by Red Hat Linux 7.2, and should be present in all other Linux distributions soon.