JFS: IBM Really, Really Supports Linux
Say what you want about IBM and its traditional taste in clothing, but IBM has come out of the Linux closet in a big way. IBM is one of the staunchest supporters of Linux, and is one of its heaviest promoters as an enterprise business solution. IBM shocked everybody when it invested heavily in the Apache Web server project in 1998some of the most surprised people being IBM employees who were working on other Web servers and barely heard the huge flushing noise before they had to scramble to find other projects.
To the benefit of the entire Linux community, IBM has also released some of its most interesting and innovative software projects to the Open Source community. Two of these are discussed in this series of articles: OpenAFS, the open-source version of IBM's AFS distributed filesystem product; and JFS, its Journal File System, which is the subject of this section.
JFS is IBM's full journaling filesystem, originally developed for use on its AIX and OS/2 systems, but now released to the Open Source community via the Gnu Public License (GPL). This history gives JFS some advantages over newer journaling filesystems such as ReiserFS because the code base has undergone extensive testing under other operating systems.
JFS is a full 64-bit filesystem, giving it a potential capacity of between 512 terabytes and 32 petabytes per filesystem, depending on the block size used when a filesystem is created. In theory, JFS supports block sizes of 512, 1024, 2048, and 4096 bytes, but only the block size of 4096 bytes is currently supported in Linux. Like other 64-bit filesystems under Linux at the moment, the true capacity of JFS is limited by constraints within the Linux VFS layer, so the actual maximum capacity of a JFS filesystem in the 2.4 Linux kernel family is 16 terabytes, based on VFS limitations.
Certain aspects of JFS use their own terminology, which shouldn't surprise anyone accustomed to using products from IBM. IBM uses the term "aggregate" to refer to a pool of available storage such as a formatted disk partition, formatted disk, or logical volume. One or more filesets (what we would typically think of as filesystems) can then be created and managed within an aggregate using the mkfs.jfs utility. Both aggregates and filesets therefore contain superblock and related information about the storage that they represent.
JFS logs information about changes to filesystem metadata as atomic transactions. If the system is restarted without cleanly unmounting a JFS fileset, any transactions in the log that are not marked as having been completed on disk are replayed when the filesystem is checked for consistency before it is mounted, restoring the consistency of the filesystem metadata. Because the log contains metadata only, rather than actual user data, this guarantees the structural consistency of the filesystem but not the contents of the files in the filesystem. Files being edited when the system went down will not reflect any updates not successfully written to disk.
The actual log for a JFS fileset is maintained in the JFS aggregate where that fileset is located. A single log can be used by multiple filesets at the same time (after JFS on Linux supports multiple filesets within an aggregate). At the moment, each aggregate contains both a single fileset and a single log.
JFS is designed to maximize performance and minimize inherent limitations as much as possible. Like XFS, JFS does not preallocate inodes, but allocates them as needed when files and directories are created. As with other filesystems that dynamically allocate inodes, this helps remove potential limitations in the number of files and directories that can be created in a JFS fileset.
JFS is a high-performance journaling filesystem that is already available in cutting-edge desktop Linux distributions such as SuSE Linux.