3.5. Linux File Systems

Defining what actually is a "Linux" file system is difficult. Exchange between Unix flavors is vivid. Some of these file systems are borrowed from other flavors, others have been ported from Linux to other systems.

3.5.1. ext2 and ext3

The ext2 file system is "the" native file system for Linux nowadays. There was a predecessor simply called "extended" file system, but support for it has long been eliminated from the Linux kernel. ext3 is a backwards-compatible extension that adds meta-data journalling.

ext2 is a fairly plain Unix file system, using an allocation bitmap and inodes. It has a superblock stored 1024 bytes into the device, independent of the block size used. All data is stored in little-endian byte order. The superblock contains some information not yet printed by disktype, including the originating operating system.

Information on ext2 can be found at http://www.nongnu.org/ext2-doc/. Other sources are the home page of the ext2 tools at http://e2fsprogs.sourceforge.net/, and the Linux kernel source code (see Chapter 4, Other Sources of Information).

3.5.2. ReiserFS

ReiserFS was written with efficiency in mind. It handles large numbers of files per directory and large numbers of small files in general better than most traditional file systems. It makes extensive use of balanced trees and also provides meta-data journalling.

There are two major versions of the on-disk format, 3.5 and 3.6. ReiserFS on Linux 2.2 only supports the 3.5 format. Linux 2.4 ships with ReiserFS in the mainstream kernel, supports both formats, and is able to upgrade a file system on the fly to the new format. The two formats use two different magic strings in the superblock. A third magic string is used for non-standard journal sizes. (It seems this feature was added only recently and isn't actually supported by the mainstream Linux kernel yet.) In this case, the format is determined by an additional field in the superblock.

ReiserFS puts the superblock 64K into the device; some earlier versions put it 8K into the device. That allows complex boot loaders like GRUB to reside completely in the space before the actual file system. All data is stored in little-endian byte order.

Information on ReiserFS can be found at http://www.namesys.com/.

3.5.3. Reiser4

Reiser4 is the successor to ReiserFS, further improving on some algorithms and data structures. Many aspects of Reiser4 are separate plug-ins and can be swapped. As a result, Reiser4 only stores a "master superblock" 64K into the device that serves as an anchor to the rest of the file system, including the actual superblock. The default 4.0 format stores it in the following 4K block (i.e., 68K into the device).

3.5.4. Minix

As the name suggests, the Minix format didn't originate on Linux, but on Minix, the PC Unix system after which Linux was modelled in its early days. The format is quite simple and compact, and was the preferred format for boot and install floppies for some time. Today, it has been superceded by ext2, and support for it will likely be removed in the next stable Linux kernel series.

Minix puts the superblock 1K into the device. There are two versions of the volume structures (most notably the inodes), and two maximum lengths for file names (14 or 30 chars). These parameters can be combined, yielding four actual formats, each with its own magic. disktype assumes that Minix is always little-endian, but I wasn't able to really confirm this yet.

3.5.5. romfs

romfs is a read-only file system intended for boot disks, initial ramdisks and the like. It does not use compression. When used with initrd, it can be stored in compressed form on the boot medium and is decompressed in whole while loading it into the ramdisk. The code for romfs is quite small, which results from data structures optimized for the Linux kernel.

Information on romfs can be found at http://romfs.sourceforge.net/.

3.5.6. cramfs

cramfs is a read-only file system intended for boot disks, initial ramdisks and the like. It improves on romfs by using compression within the file system. Decompression happens block by block as file data is accessed.

cramfs uses the native byte order and page size of each architecture, but doesn't store these parameters in the superblock. disktype determines the byte order from the magic number field, but the page size can only be guessed at. The superblock can start at the beginning of the device, or after one unused sector of 512 bytes.

Information on cramfs can be found at http://sourceforge.net/projects/cramfs/.

3.5.7. squashfs

squashfs is a read-only file system intended for boot disks, initial ramdisks and the like, currently under development. It tries to pack data really tight, without padding. A squashfs file system can occur with both byte orders, and the current Linux driver can use both, independent of the running architecture. The byte order can be determined from the magic number.

Information on squashfs can be found at http://squashfs.sourceforge.net/.