Filesystem Visualizer: ext4 on one screen.

Why ext4 cuts the disk into groups

The same trick computer architects use for memory.

Ext4 divides the disk into block groups of roughly 128 MiB each. Every block group has its own copy of the superblock metadata (for redundancy), its own inode bitmap, its own block bitmap, its own inode table, and the actual data blocks. A file's inode and its data blocks live in the same block group whenever possible, with directory entries clustered nearby. Each directory is assigned a "preferred group" at creation, and files in that directory try to land there.

The benefit is mechanical sympathy with the storage device. On spinning rust, reading the inode and the data without a long seek is much faster than scattering them across the platter. On an SSD, the seek argument is gone but the locality still helps for read-ahead and for keeping a working set of bitmaps in the page cache. The pattern is the same one CPUs use for cache lines — pack things you'll access together. The cost is that very large files (multi-GB) span groups and lose the benefit, which is why ext4 added extents (contiguous-extent descriptors) instead of the old single-block pointer array of ext2/3.

A file's identity isn't its name

The directory entry maps the name to a number. The number is the file.

An inode is a fixed-size structure (256 bytes on modern ext4) holding everything about a file except its name: mode bits, owner, size, modification times, refcount, and the extent tree pointing at where the data lives. The filename is in the directory entry of some parent directory, not in the inode. This is why renaming a file is atomic and cheap (rewrite one dirent), why hard links work (multiple dirents point at the same inode), and why unlinking a file whose fd is still open doesn't actually delete the data (the inode's refcount only drops to zero when the last reference, dirent or fd, is gone).

This is also why df can report a disk is "full" when only 30% of the data blocks are used — the inode table is fixed at filesystem-creation time, and you can run out of inodes (think: a Maildir with a million tiny messages) long before you run out of data blocks. The fix is mkfs.ext4 -N to allocate more inodes up front. XFS dynamically allocates inodes so this problem doesn't appear.

The journal makes the filesystem survivable

The same idea databases use for crash recovery, applied one layer down.

Without a journal, any modification that touches multiple metadata blocks (creating a file touches the inode bitmap, the inode table, the parent directory entry, and the block bitmap) risks leaving the filesystem in an inconsistent state if the machine crashes mid-modification. The classic ext2 era of "fsck takes 45 minutes on a 1 TB disk" was a direct consequence — fsck had to scan everything looking for inconsistencies because nothing recorded what had been in flight.

Ext4's journal (managed by the JBD2 layer) records every metadata transaction before it updates the in-place blocks. A transaction is opened; the about-to-change metadata blocks are copied into the journal; an in-place update happens; a commit record is written to the journal. On crash, the kernel mounts the FS, reads the journal, and replays any committed-but-not-yet-applied transactions, discarding any started-but-not-committed ones. The filesystem is consistent the moment the mount finishes. No global scan needed.

This is why ext4 fsck on a clean unmount takes a second; on a dirty mount it takes only as long as the journal replay (a few seconds, even on multi-TB filesystems). The data may still need recovery — that depends on the journal mode — but the filesystem structure itself is always recoverable in constant time relative to the journal size, not the disk size.