Blocks¶

The space in the device or file is split up into blocks. These area fixed size, of 1024, 2048 or 4096 bytes (8192 bytes on Alpha systems),which is decided when the filesystem is created. Smaller blocks meanless wasted space per file, but require slightly more accounting overhead,and also impose other limits on the size of files and the filesystem.

Block Groups¶

Blocks are clustered into block groups in order to reduce fragmentationand minimise the amount of head seeking when reading a large amountof consecutive data. Information about each block group is kept in adescriptor table stored in the block(s) immediately after the superblock.Two blocks near the start of each group are reserved for the block usagebitmap and the inode usage bitmap which show which blocks and inodesare in use. Since each bitmap is limited to a single block, this meansthat the maximum size of a block group is 8 times the size of a block.

The block(s) following the bitmaps in each block group are designatedas the inode table for that block group and the remainder are the datablocks. The block allocation algorithm attempts to allocate data blocksin the same block group as the inode which contains them.

The Superblock¶

The superblock contains all the information about the configuration ofthe filing system. The primary copy of the superblock is stored at anoffset of 1024 bytes from the start of the device, and it is essentialto mounting the filesystem. Since it is so important, backup copies ofthe superblock are stored in block groups throughout the filesystem.The first version of ext2 (revision 0) stores a copy at the start ofevery block group, along with backups of the group descriptor block(s).Because this can consume a considerable amount of space for largefilesystems, later revisions can optionally reduce the number of backupcopies by only putting backups in specific groups (this is the sparsesuperblock feature). The groups chosen are 0, 1 and powers of 3, 5 and 7.

The information in the superblock contains fields such as the totalnumber of inodes and blocks in the filesystem and how many are free,how many inodes and blocks are in each block group, when the filesystemwas mounted (and if it was cleanly unmounted), when it was modified,what version of the filesystem it is (see the Revisions section below)and which OS created it.

If the filesystem is revision 1 or higher, then there are extra fields,such as a volume name, a unique identification number, the inode size,and space for optional filesystem features to store configuration info.

All fields in the superblock (as in all other ext2 structures) are storedon the disc in little endian format, so a filesystem is portable betweenmachines without having to know what machine it was created on.

Inodes¶

The inode (index node) is a fundamental concept in the ext2 filesystem.Each object in the filesystem is represented by an inode. The inodestructure contains pointers to the filesystem blocks which contain thedata held in the object and all of the metadata about an object exceptits name. The metadata about an object includes the permissions, owner,group, flags, size, number of blocks used, access time, change time,modification time, deletion time, number of links, fragments, version(for NFS) and extended attributes (EAs) and/or Access Control Lists (ACLs).

There are some reserved fields which are currently unused in the inodestructure and several which are overloaded. One field is reserved for thedirectory ACL if the inode is a directory and alternately for the top 32bits of the file size if the inode is a regular file (allowing file sizeslarger than 2GB). The translator field is unused under Linux, but is usedby the HURD to reference the inode of a program which will be used tointerpret this object. Most of the remaining reserved fields have beenused up for both Linux and the HURD for larger owner and group fields,The HURD also has a larger mode field so it uses another of the remainingfields to store the extra more bits.

There are pointers to the first 12 blocks which contain the file’s datain the inode. There is a pointer to an indirect block (which containspointers to the next set of blocks), a pointer to a doubly-indirectblock (which contains pointers to indirect blocks) and a pointer to atrebly-indirect block (which contains pointers to doubly-indirect blocks).

The flags field contains some ext2-specific flags which aren’t cateredfor by the standard chmod flags. These flags can be listed with lsattrand changed with the chattr command, and allow specific filesystembehaviour on a per-file basis. There are flags for secure deletion,undeletable, compression, synchronous updates, immutability, append-only,dumpable, no-atime, indexed directories, and data-journaling. Not allof these are supported yet.

Directories¶

A directory is a filesystem object and has an inode just like a file.It is a specially formatted file containing records which associateeach name with an inode number. Later revisions of the filesystem alsoencode the type of the object (file, directory, symlink, device, fifo,socket) to avoid the need to check the inode itself for this information(support for taking advantage of this feature does not yet exist inGlibc 2.2).

The inode allocation code tries to assign inodes which are in the sameblock group as the directory in which they are first created.

The current implementation of ext2 uses a singly-linked list to storethe filenames in the directory; a pending enhancement uses hashing of thefilenames to allow lookup without the need to scan the entire directory.

The current implementation never removes empty directory blocks once theyhave been allocated to hold more files.

Special files¶

Symbolic links are also filesystem objects with inodes. They deservespecial mention because the data for them is stored within the inodeitself if the symlink is less than 60 bytes long. It uses the fieldswhich would normally be used to store the pointers to data blocks.This is a worthwhile optimisation as it we avoid allocating a fullblock for the symlink, and most symlinks are less than 60 characters long.

Character and block special devices never have data blocks assigned tothem. Instead, their device number is stored in the inode, again reusingthe fields which would be used to point to the data blocks.

Reserved Space¶

In ext2, there is a mechanism for reserving a certain number of blocksfor a particular user (normally the super-user). This is intended toallow for the system to continue functioning even if non-privileged usersfill up all the space available to them (this is independent of filesystemquotas). It also keeps the filesystem from filling up entirely whichhelps combat fragmentation.

Filesystem check¶

At boot time, most systems run a consistency check (e2fsck) on theirfilesystems. The superblock of the ext2 filesystem contains severalfields which indicate whether fsck should actually run (since checkingthe filesystem at boot can take a long time if it is large). fsck willrun if the filesystem was not cleanly unmounted, if the maximum mountcount has been exceeded or if the maximum time between checks has beenexceeded.

Feature Compatibility¶

The compatibility feature mechanism used in ext2 is sophisticated.It safely allows features to be added to the filesystem, withoutunnecessarily sacrificing compatibility with older versions of thefilesystem code. The feature compatibility mechanism is not supported bythe original revision 0 (EXT2_GOOD_OLD_REV) of ext2, but was introduced inrevision 1. There are three 32-bit fields, one for compatible features(COMPAT), one for read-only compatible (RO_COMPAT) features and one forincompatible (INCOMPAT) features.

These feature flags have specific meanings for the kernel as follows:

A COMPAT flag indicates that a feature is present in the filesystem,but the on-disk format is 100% compatible with older on-disk formats, soa kernel which didn’t know anything about this feature could read/writethe filesystem without any chance of corrupting the filesystem (or evenmaking it inconsistent). This is essentially just a flag which says“this filesystem has a (hidden) feature” that the kernel or e2fsck maywant to be aware of (more on e2fsck and feature flags later). The ext3HAS_JOURNAL feature is a COMPAT flag because the ext3 journal is simplya regular file with data blocks in it so the kernel does not need totake any special notice of it if it doesn’t understand ext3 journaling.

An RO_COMPAT flag indicates that the on-disk format is 100% compatiblewith older on-disk formats for reading (i.e. the feature does not changethe visible on-disk format). However, an old kernel writing to such afilesystem would/could corrupt the filesystem, so this is prevented. Themost common such feature, SPARSE_SUPER, is an RO_COMPAT feature becausesparse groups allow file data blocks where superblock/group descriptorbackups used to live, and ext2_free_blocks() refuses to free these blocks,which would leading to inconsistent bitmaps. An old kernel would alsoget an error if it tried to free a series of blocks which crossed a groupboundary, but this is a legitimate layout in a SPARSE_SUPER filesystem.

An INCOMPAT flag indicates the on-disk format has changed in someway that makes it unreadable by older kernels, or would otherwisecause a problem if an old kernel tried to mount it. FILETYPE is anINCOMPAT flag because older kernels would think a filename was longerthan 256 characters, which would lead to corrupt directory listings.The COMPRESSION flag is an obvious INCOMPAT flag - if the kerneldoesn’t understand compression, you would just get garbage back fromread() instead of it automatically decompressing your data. The ext3RECOVER flag is needed to prevent a kernel which does not understand theext3 journal from mounting the filesystem without replaying the journal.

For e2fsck, it needs to be more strict with the handling of theseflags than the kernel. If it doesn’t understand ANY of the COMPAT,RO_COMPAT, or INCOMPAT flags it will refuse to check the filesystem,because it has no way of verifying whether a given feature is validor not. Allowing e2fsck to succeed on a filesystem with an unknownfeature is a false sense of security for the user. Refusing to checka filesystem with unknown features is a good incentive for the user toupdate to the latest e2fsck. This also means that anyone adding featureflags to ext2 also needs to update e2fsck to verify these features.

Metadata¶

It is frequently claimed that the ext2 implementation of writingasynchronous metadata is faster than the ffs synchronous metadatascheme but less reliable. Both methods are equally resolvable by theirrespective fsck programs.

If you’re exceptionally paranoid, there are 3 ways of making metadatawrites synchronous on ext2:

• per-file if you have the program source: use the O_SYNC flag to open()
• per-file if you don’t have the source: use “chattr +S” on the file
• per-filesystem: add the “sync” option to mount (or in /etc/fstab)

the first and last are not ext2 specific but do force the metadata tobe written synchronously. See also Journaling below.

Limitations¶

There are various limits imposed by the on-disk layout of ext2. Otherlimits are imposed by the current implementation of the kernel code.Many of the limits are determined at the time the filesystem is firstcreated, and depend upon the block size chosen. The ratio of inodes todata blocks is fixed at filesystem creation time, so the only way toincrease the number of inodes is to increase the size of the filesystem.No tools currently exist which can change the ratio of inodes to blocks.

Most of these limits could be overcome with slight changes in the on-diskformat and using a compatibility flag to signal the format change (atthe expense of some compatibility).

There is a 2.4 kernel limit of 2048GB for a single block device, so nofilesystem larger than that can be created at this time. There is alsoan upper limit on the block size imposed by the page size of the kernel,so 8kB blocks are only allowed on Alpha systems (and other architectureswhich support larger pages).

There is an upper limit of 32000 subdirectories in a single directory.

There is a “soft” upper limit of about 10-15k files in a single directorywith the current linear linked-list directory implementation. This limitstems from performance problems when creating and deleting (and alsofinding) files in such large directories. Using a hashed directory index(under development) allows 100k-1M+ files in a single directory withoutperformance problems (although RAM size becomes an issue at this point).

The (meaningless) absolute upper limit of files in a single directory(imposed by the file size, the realistic limit is obviously much less)is over 130 trillion files. It would be higher except there are notenough 4-character names to make up unique directory entries, so theyhave to be 8 character filenames, even then we are fairly close torunning out of unique filenames.

Journaling¶

A journaling extension to the ext2 code has been developed by StephenTweedie. It avoids the risks of metadata corruption and the need towait for e2fsck to complete after a crash, without requiring a changeto the on-disk ext2 layout. In a nutshell, the journal is a regularfile which stores whole metadata (and optionally data) blocks that havebeen modified, prior to writing them into the filesystem. This meansit is possible to add a journal to an existing ext2 filesystem withoutthe need for data conversion.

When changes to the filesystem (e.g. a file is renamed) they are stored ina transaction in the journal and can either be complete or incomplete atthe time of a crash. If a transaction is complete at the time of a crash(or in the normal case where the system does not crash), then any blocksin that transaction are guaranteed to represent a valid filesystem state,and are copied into the filesystem. If a transaction is incomplete atthe time of the crash, then there is no guarantee of consistency forthe blocks in that transaction so they are discarded (which means anyfilesystem changes they represent are also lost).Check Documentation/filesystems/ext4/ if you want to read more aboutext4 and journaling.