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

mkfs.ext4 /dev/sdb1 mkfs.ext4 -L mydata /dev/sdb1 # with a volume label tune2fs -l /dev/sdb1 # list current filesystem parameters tune2fs -L newlabel /dev/sdb1 # change the label after creation

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

fsck.ext4 /dev/sdb1

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."

ModeWhat's protectedRelative speed
journalData and metadataSlowest
ordered (default)Metadata, with data ordered before it commitsBalanced
writebackMetadata onlyFastest
Check the real journaling mode directly
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.
Never run fsck on a mounted, in-use filesystem
A genuinely serious, easy-to-make mistake: running 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

Exercise 1

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 solution
Exercise 2

Explain 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 solution
Exercise 3

A 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 solution

Chapter 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.ext4 creates; tune2fs adjusts parameters afterward without reformatting
  • fsck.ext4 checks/repairs — never on a mounted, actively-used filesystem
  • dumpe2fs -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