The choice usually gets made at install time, in thirty seconds, on whatever the default is. Then data piles up for years, and that choice becomes very hard to walk back.
Yet the four candidates do not mainly differ on performance. They differ on a question that matters far more for storage: do they know whether your data is still intact?
The dividing line: data checksums
All of these filesystems protect their metadata — the directory tree, the permissions, where the blocks live. That is what journaling is for, and it does its job well when the power cuts out.
But only ZFS and Btrfs compute a checksum over the contents of every block and verify it on every read.
The difference is considerable. Without that verification, an altered block is handed back to the application as if it were valid. The file opens; it is simply wrong. With it, the alteration is detected immediately — and if redundancy exists, repaired from a good copy, transparently.
Silent corruption, the risk you never see
This is the failure mode specific to long-term storage, and the most insidious one.
The causes vary: failing memory, a micro-defect in the medium, a controller error, a mediocre cable. The result is always the same: a block changes and nobody is told.
What comes next is the worst part. Your backup faithfully copies the corrupted file. After a few retention cycles, every one of your versions contains the corruption. You discover the problem years later, opening a pixelated photo, and there is no clean version left anywhere.
The four candidates
ext4 is mature, fast, supported everywhere, and its repair tools are thoroughly battle-tested. It is the right choice for a system disk, a virtual machine, or any volume whose contents are replaceable. On data kept for a long time, its lack of content verification is its one real weakness — but that weakness is structural.
XFS excels at large files and parallel writes: it is an excellent choice for media or backup storage, particularly on an array that is already redundant. It grows online but never shrinks — a constraint worth knowing before you size anything. Like ext4, it does not verify the contents of your data.
ZFS is the most complete: checksums, snapshots that are instant and nearly free, very effective transparent compression, built-in redundancy management, and periodic verification of the entire volume. Its price is discipline: you have to think about topology from day one, because pulling a disk out of an existing group remains constrained, and you have to keep an eye on its memory cache when it runs on a hypervisor.
Btrfs offers the same integrity guarantees, built into the kernel, with remarkable flexibility: disks added and removed online, profile conversion, genuinely handy snapshots and subvolumes. The caveat is clear-cut: its parity RAID modes remain inadvisable for important data. Mirrored, or as a simple pooled volume, it is a perfectly sound choice.
The ECC memory debate
"ZFS requires ECC memory" gets repeated a lot and deserves to be pinned down, because that belief talks people out of setups that are perfectly viable.
ZFS guarantees data integrity on disk. If memory corrupts a block before its checksum is computed, ZFS dutifully records the corrupted version with a valid checksum. ECC memory closes that window.
But that reasoning applies to every filesystem: failing memory corrupts an ext4 just as happily. ZFS is not more fragile, it is simply more explicit about the limits of its guarantee. ECC is strongly recommended on a storage server; its absence is not a reason to give up on ZFS.
Choosing in one sentence
- System disk, virtual machine, replaceable data: ext4. Simple, fast, no surprises.
- Large files on a redundant array: XFS, keeping in mind that it never shrinks.
- Data you do not want to lose, spread over several disks: ZFS, if you are willing to design the topology seriously.
- Integrity plus room to evolve, mirrored: Btrfs, steering clear of its parity modes.
And whatever you choose, a periodic verification of the whole volume is worth scheduling: on ZFS and Btrfs it detects and repairs, on ext4 and XFS it will at least tell you the disks still answer. That is what stops you from discovering a fault in the middle of an array rebuild.
Comments