ext4 and btrfs are the two filesystems a Linux desktop or server actually chooses between in 2026. ext4 is the dependable default that has carried Debian, Ubuntu, and Fedora installs for over a decade; btrfs trades some of that conservatism for snapshots, checksums, and built-in compression. Both are excellent — for different definitions of excellent.
What each one optimises for #
| Capability | ext4 | btrfs |
|---|---|---|
| Maturity | Decades of production use | Mature, still evolving |
| Checksums | Metadata only (journal) | All data and metadata |
| Snapshots | No (need LVM) | Built-in, instant |
| Compression | No | zstd, transparent |
| Subvolumes | No | Yes — flexible layouts |
| Resize | Offline shrink, online grow | Online both ways |
| Recovery story | fsck, well understood | scrub, self-healing with redundancy |
The checksum row is the philosophical divide: btrfs detects silent corruption — bit rot, misbehaving cables, firmware lies — because every block carries one. ext4 trusts the hardware and journals for crashes, not decay.
Working with each #
Day to day, both are invisible. The moments they differ:
$ sudo btrfs subvolume snapshot / /snapshots/pre-updateThat instant snapshot is btrfs's headline act — the basis of openSUSE and Fedora's system rollback, and the reason "I'll just try the update" stops being a gamble on those systems.
$ sudo btrfs scrub start /$ sudo touch /forcefsck # or: fsck from recovery, unmountedChoosing honestly #
ext4 remains the right answer when you want the filesystem to be boring: maximum compatibility, predictable performance, tools every rescue ISO carries. btrfs is the right answer when snapshots or compression pay rent — rolling system updates, build trees that compress hugely, datasets that deserve checksums. On servers with many disks, xz/zfs also enter the conversation; on the desktop it is genuinely these two.
Sizing and disk math live in df and du; the underlying device work is dd. The terminal notes series continues.