the ext file system

If you have used Linux, your files most likely lived on ext — the extended file system, the default family of Linux file systems for decades. It is the most familiar real-world example of all the ideas in this field stitched together: inodes, a superblock, a free-space bitmap, multilevel indexing, directories, and (from ext3 onward) a journal. Tracing its three main versions is a tidy tour of how a practical file system evolved.

Here is the structural shape. An ext volume is divided into block groups, each a self-contained mini file system holding its own inode bitmap, block bitmap, a slice of the inode table, and data blocks (keeping a file's inode and data near each other reduces seeks). The superblock (with backups in several block groups) holds the volume-wide metadata. Each file has an inode using the classic multilevel index: 12 direct pointers plus single-, double-, and triple-indirect blocks. ext2 was this clean design with no journal — fast, but a crash meant a slow full fsck. ext3 added a journal (write-ahead logging of metadata) so recovery became a quick replay instead of a full scan, while keeping the same on-disk layout so the two were largely compatible. ext4 then modernized it: it replaced the indirect-block scheme for large files with extents (an extent records start block plus length, describing a long contiguous run with one entry instead of thousands of pointers), added htree-indexed directories for fast lookup in huge folders, delayed allocation, and support for much larger files and volumes.

ext matters as the concrete, battle-tested embodiment of this field's theory — when you read about an inode or a journal in the abstract, ext is where you can actually see it in a running system. One honest note: ext is a journaling, in-place-update file system, a different design point from copy-on-write systems like btrfs and ZFS; it does not provide their cheap snapshots or block checksums, trading those features for simplicity, maturity, and predictable performance.