← Interview Prep

Linux Kernel — The Ext2/Ext3/Ext4 Filesystems

On-disk layout: superblock, block groups, inode/block bitmaps and the inode table; inodes with indirect blocks (ext2/3) vs extents & delayed allocation & htree dirs (ext4); directories as name→inode files; journaling modes (journal/ordered/writeback); and ext2 vs ext3 vs ext4.

How a classic Linux filesystem lays itself out on disk, and what journaling (ext3) and extents (ext4) added. The concrete storage under the VFS. Original, interview-focused notes.

An ext filesystem divides the disk into block groups, each with its own inode table, bitmaps, and data blocks. A file's inode holds its metadata and pointers to data blocks; a directory is just a file mapping names → inode numbers. ext3 added a journal; ext4 replaced block pointers with extents.

On-disk layout

Structure	Holds
Superblock	Filesystem-wide metadata (size, block size, counts, feature flags). Backed up in several block groups.
Block group	The disk is split into groups so related data/metadata stay close (locality → fewer seeks on HDD).
Inode & block bitmaps	One bit per inode/block — free or used.
Inode table	The array of inodes (metadata + data-block map). Count fixed at `mkfs`.
Data blocks	The file contents themselves.

Because inode count is fixed at format time, a filesystem can run out of inodes while blocks are free — the classic ENOSPC-with-space bug (df -i). See Linux Troubleshooting.

Inodes: indirect blocks vs extents

ext2/3 (indirect blocks): the inode has a few direct block pointers plus single/double/triple indirect pointers — a tree that scales to big files but is pointer-heavy and scatters large files.
ext4 (extents): an extent maps a range of contiguous blocks in one record — far less metadata and better contiguity for large files. Plus delayed allocation (decide placement at writeback, not at write) and htree-indexed directories (fast lookups in huge dirs).
A directory is a special file whose contents are name→inode entries; . and .. are entries too. Names live here, not in the inode — which is why hard links (many names, one inode) work.

Journaling — the ext3/ext4 addition

Without a journal, a crash mid-update can leave the filesystem inconsistent, needing a slow full fsck. A journal records intended changes first, so recovery just replays/discards the log — fast and safe. ext3/ext4 offer three modes:

Mode	Journals	Trade-off
journal	Metadata and data	Safest, slowest (data written twice).
ordered (default)	Metadata only, but data is forced to disk before the metadata commits	Good balance — no stale-data exposure after a crash.
writeback	Metadata only, no data ordering	Fastest; a crash can expose stale block contents in a just-extended file.

Journaling protects consistency, not your unflushed data — durability still needs fsync (see Page Cache).

ext2 vs ext3 vs ext4

ext2 — no journal (fast, but a crash means full fsck). Still used on tiny/flash volumes where journal writes aren't wanted.
ext3 — ext2 + journaling; largely on-disk compatible.
ext4 — extents, delayed allocation, htree dirs, larger limits, checksums — the long-time Linux default (with XFS/Btrfs as alternatives).

Likely interview questions

Describe the on-disk layout — superblock, block groups, inode table, bitmaps, data.
Why can a filesystem be "full" with free space? (inodes fixed at mkfs; df -i)
Indirect blocks vs extents — why did ext4 switch? (metadata size, contiguity)
What is a directory, really, and how do hard links follow from it? (name→inode file; names outside the inode)
What does journaling protect, and what are the journal modes? (consistency; journal/ordered/writeback)
Does a journal make your data durable? (no — still need fsync)
ext2 vs ext3 vs ext4 in one line each.

Kernel Internals series. Related: The VFS · Page Cache · Linux Troubleshooting.