ext4 — The Traditional Default
Linux Filesystems
Chapter 2 · ext4 — The Traditional Default
fs1-1 previewed journaling without explaining the mechanism. This chapter delivers that in full, plus everything else that makes ext4 the long-standing default Linux filesystem — and an honest answer to when it's still the right choice.
Journaling — Delivering on Chapter 1's Own Preview
Before making a change to the actual filesystem structure, ext4 first writes a small record of the intended change to a dedicated journal area. If the system crashes mid-operation, on the next mount ext4 replays the journal to either complete or cleanly roll back the incomplete change — avoiding the pre-journaling era's own slow, full-filesystem scan after every unclean shutdown.
- journal — full data and metadata journaling; the safest mode, the slowest
- ordered (the default) — metadata is journaled; actual data is written before its metadata commits — a genuinely good balance
- writeback — metadata only; the fastest, but the weakest guarantee — data itself could still be corrupted after a crash even though the filesystem's own structure stays consistent
Extents — A Real Improvement Over Block Mapping
Older filesystems (ext2/ext3) tracked a file's data location as a long list of individual block pointers — genuinely inefficient for a large, mostly contiguous file, which might need thousands of individual pointers. ext4's own extents represent a large contiguous run of blocks as one compact record — "blocks N through N+1000 belong to this file" — dramatically more efficient for large files, both in metadata size and in reducing fragmentation-related overhead.
Creating and Tuning an ext4 Filesystem
tune2fs is the real, primary tool for adjusting ext4 parameters after creation — labels, reserved-block percentage, forced-check intervals — without needing to reformat and lose everything.
fsck — Checking and Repairing
Checks, and can repair, filesystem consistency. Genuinely important: the check assumes nothing else is actively modifying the filesystem while it runs. For a root filesystem that can't simply be unmounted while running, grub1-9's own chroot-rescue material is directly relevant — boot a live environment, mount the target filesystem there instead, and run fsck from outside it.
When ext4 Is Still the Right Choice
ext4 is mature, extremely well-tested, has the broadest compatibility and tooling support of any Linux filesystem, and has genuinely lower resource overhead than fs1-3's Btrfs or fs1-4's ZFS. The right default when you don't specifically need snapshots, checksumming, or integrated volume management, and simplicity, stability, and raw performance matter most. Btrfs and ZFS aren't free upgrades over ext4 — each trades some of this simplicity for genuinely new capabilities, a real tradeoff this course takes seriously rather than treating ext4 as simply "the old one."
| Mode | What's protected | Relative speed |
|---|---|---|
| journal | Data and metadata | Slowest |
| ordered (default) | Metadata, with data ordered before it commits | Balanced |
| writeback | Metadata only | Fastest |
dumpe2fs -h /dev/sdb1 reads the actual superblock and shows the current journaling mode and other real filesystem parameters — fs1-1's own superblock material, made directly checkable.
fsck against a filesystem that's currently mounted and actively being written to can itself cause corruption — the exact opposite of the intended effect. Always unmount first, or check from a live/rescue environment for a root filesystem that can't be unmounted while running.
Hands-On Exercises
Explain, using this chapter's own three journaling modes, which mode you'd choose for a database server where data integrity matters more than raw write speed, and why.
📄 View solutionExplain why extents are a genuine improvement over block-by-block mapping specifically for a large, mostly-contiguous file like a video, referencing what each approach actually stores.
📄 View solutionA system administrator wants to run fsck on the currently-mounted root filesystem while the system is up and running. Explain why this is dangerous, and the correct alternative approach.
📄 View solutionChapter 2 Quick Reference
- journal (safest/slowest), ordered (default, balanced), writeback (fastest/weakest) — the three real journaling modes
- Extents represent contiguous block runs compactly, a real improvement over per-block mapping for large files
mkfs.ext4creates;tune2fsadjusts parameters afterward without reformattingfsck.ext4checks/repairs — never on a mounted, actively-used filesystemdumpe2fs -h— read real filesystem parameters directly from the superblock- ext4 remains the right default for maturity, compatibility, and low overhead when snapshots/checksumming/integrated volumes aren't specifically needed
- Btrfs (fs1-3) and ZFS (fs1-4) trade ext4's simplicity for genuinely new capabilities — real tradeoffs, not free upgrades