ZFS vs Btrfs vs ext4: What Should You Use in 2026?

ZFS, Btrfs, and ext4 are all good filesystems in 2026, which is exactly why the question is hard. Pick the wrong one and you do not lose data, at least not anymore; pick the wrong one for your workload and you spend the next five years working around a decision you made in an afternoon. Most comparisons stop at feature checklists as if a feature were the same thing as an operational guarantee. It is not, because the three answer one question very differently: who is on the hook when a disk starts returning garbage?

OpenZFS answers: the filesystem, radically and completely. Copy-on-write everywhere, checksums on every block including data, self-healing against redundancy, snapshots, send/receive, compression, and its own volume manager, at the cost of living outside the mainline kernel. Btrfs answers: the filesystem, pragmatically. Copy-on-write, checksums, transparent compression, snapshots and send/receive in the mainline kernel, with parity RAID as the known weak spot. ext4 answers: nobody wants that job. It keeps your bytes where you put them, with the least machinery possible and the most battle scars possible, and leaves snapshots, checksums-on-data, and pooling to the layer above (LVM, dm-integrity, backups).

This is the storage layer of questions this site keeps circling, and a sibling to pieces like our immutable node OS comparison and the Proxmox vs IncusOS breakdown, both of which end up reading storage choices sooner or later. Here, the destination is the same for all three candidates, so what differs is the day-2 reality: what survives a bad disk, what survives a bad decision, and what the next five kernel versions do to you.

The short version

• ext4 is still the default almost everywhere, and still the right default almost everywhere. No filesystem in history has been debugged harder. It does not checksum data, it has no native snapshots, and it will never grow a pool, but it needs nothing from you and forgives almost everything.
• Btrfs is production-ready for single-disk and mirror setups, and still not for parity RAID. It is the default on Fedora (since Fedora 33) and openSUSE, gives you snapshots, checksums, compression, and send/receive in the mainline kernel, but its RAID56 remains explicitly not production-ready. The raid-stripe-tree that is supposed to underpin a write-hole-free replacement landed back in kernel 6.7, and a June 2026 RFC is the first serious move toward RAID5 on top of it, but it is an early design review, not something you can run.
• OpenZFS is the most capable and the most demanding. OpenZFS 2.4.4 (released August 21, 2026, with Linux 7.2 support) gives you self-healing checksummed storage with RAIDZ that even in this era keeps improving (RAIDZ pool expansion landed in 2.3), but it lives outside the mainline kernel for licensing reasons, so every kernel release is a compatibility event someone has to manage.
• Checksums on data are the real dividing line. Silent rot is not theoretical; ext4 does not detect it. If you care, that alone moves you to Btrfs or ZFS, or to ext4 plus a correcting layer you deliberately maintained.
• The boring rule survives 2026 unscathed: root volumes want ext4 unless the distro or a CoW feature is pulling you elsewhere; multi-TB data setups and anywhere backups are part of the contract want ZFS or Btrfs with mirroring, not any parity scheme, and notably not Btrfs RAID6.

What each one actually is

Three very different projects wearing similar checklists.

ext4 is the incumbent: grown out of ext3 and shipped essentially everywhere Linux is, plus a surprising amount of else (Android). The ext4 driver still mounts ext2 and ext3 filesystems, which tells you how much it is beloved and how little it throws away. It gets a new feature every so often, like the ongoing buffered I/O conversion from buffer_heads to the shared iomap path (kernel 7.3 finished iomap's VFS-level iterator rework, with measured speedups for ext4 and XFS, and for Btrfs, F2FS, and others alongside), but none of it changes its character: journaled metadata, no per-block data checksums, full fsck after unclean state when the journal cannot save you, and an enormous ecosystem of tools, rescuers, and tribal knowledge.

Btrfs is the pragmatic CoW filesystem, Oracle-born, community-maintained, mainline, and betting on being unexciting. Fedora has run it as the default root filesystem since Fedora 33, and openSUSE and SUSE Linux Enterprise have leaned on it for years precisely because the tools you want on a root volume (Snapper snapshots, rollbacks, compression, send/receive) are built in and boring. Its on-disk format has been stable for fifteen years, the tooling is first-party (scrub, balance, send/receive, device replace), and its weak spot is honestly signed: parity RAID (RAID5 and RAID6) is marked not production-ready in its own documentation, with real operational footguns (write hole, csum failures on repair). The RAID1c3 and RAID1c4 profiles are not parity at all: they are mirrors that keep three and four copies, the recommended safe answer, which is why the advice below keeps pointing at them. The long-promised fix for parity, the raid-stripe-tree, landed in kernel 6.7 (zoned-mode profiles first), and a June 2026 RFC series from a WDC developer builds RAID5 on top of it, with write-hole-free RAID5 on ordinary disks as an explicit goal, but it is posted as an early design review, not something to run. Newer experimental work like the remap-tree in kernel 7.0 does nothing to change that verdict.

OpenZFS is the appliance that people somehow administered with a text editor for fifteen years anyway. Pooled storage with vdevs, RAIDZ, mirrors, and special/dedup allocation classes (plus log, cache, and spare vdevs); checksummed and self-healing blocks; a rich feature set with compression and dedup (Fast Dedup since 2.3), snapshots, clones, send/receive with bookmarks, ARC caching, and zvol-backed block devices. It does not ship in the mainline kernel (the CDDL/GPL incompatibility is structural and not going away soon), so it is an out-of-tree project with real consequences: kernel releases have to be tested with it, distros have to carry it, and Proxmox or Ubuntu having first-class ZFS installs is not an accident but a decision that had to be made by someone.

The 2026 state of play

Nobody here is standing still, so it is worth pinning down where each project actually is.

OpenZFS 2.4 is the current line. 2.3 brought RAIDZ pool expansion (add a disk, expand a RAIDZ vdev, no re-creating the pool), Fast Dedup, and Direct IO, and the 2.4 series has been steadily polishing: current point release 2.4.4 supports Linux 7.2 with compatibility back to Linux 4.18, adds a smattering of security and plumbing improvements, and keeps FreeBSD support current. What has not changed is the positioning: it is an enormous, well-funded, well-tested out-of-tree kernel module with a bounded compatibility window and a changelog full of things like copyfilerange fixes and mount-option workarounds that exist only because mainline keeps moving underneath it.

Btrfs in 2026 is the filesystem that got boring on purpose. The feature surface (subvolumes, snapshots, compression, send/receive, mirror profiles up to RAID1c3 and RAID1c4) is stable and mature, and the on-disk format has not broken compatibility in over a decade. Boring describes the operations, not the pace: kernel 7.3 alone landed a pile of Btrfs performance work, notably direct I/O through an iomap bounce buffer instead of falling back to buffered I/O (roughly doubling DIO throughput on sample workloads) plus several fsync-path speedups. The parity RAID story is unchanged in the bad way: the raid-stripe-tree meant to underpin a write-hole-free RAID56 landed in kernel 6.7 (zoned mode first), and a June 2026 RFC series from a WDC developer extends it to RAID5 on ordinary disks, but it is posted as an early design review, RAID6 is not implemented, and RAID56 remains not production-ready. The kernel 7.0-era experimental work (the remap-tree, and direct I/O for block sizes larger than the page size) is marked experimental in the project's own kernel version notes, and enabling DIO there widened that experimental surface rather than shrinking it. The root filesystem and mirror profile use cases, meanwhile, are the mainstream deployment paths and are genuinely solid.

ext4 is getting a quiet modernization. The buffered I/O path has been migrating from the bufferhead stack to iomap in large opt-in series, and kernel 7.3 brought measured gains from two directions: at the VFS level, iomap finished converting to an iterator model with a single inlineable iomapnext() callback, which lifted ext4 and XFS (and Btrfs, F2FS, and about a dozen other filesystems with them), while ext4's own 7.3 pull allowed parallel direct I/O writes where the old locking was too conservative. None of this changes the deal: no data checksums (metadata gets checksummed; corrupted data on read returns wrong bytes without complaint), no native snapshots (use LVM-thin or backups; reflink copies are a Btrfs and XFS feature, not ext4's), no pooling, and fsck as an occasional multi-hour tax on multi-TB arrays.

Side by side

ext4: the bar other filesystems are measured against

The strongest argument for ext4 is that it is the filesystem whose failure modes entire generations of Linux operators know by heart. The strongest argument against it is nearly the same sentence: no data checksums, no snapshots, no pooling, and a repair model that taxes you exactly once at scale. It is still the answer for root volumes on most distros and the assumption baked into most tooling, including everything in a bare Debian server setup or a container host that never thinks about storage.

The iomap migration is the one genuinely new thing, and it is instructive: ext4's buffered I/O is moving from the decades-old buffer_head stack to the same path XFS uses, and the measured gains landed in kernel 7.3, from iomap's VFS-level iterator rework plus ext4's own parallel direct I/O writes. Notice what is happening there. ext4 is not growing features; it is being refit so the kernel's shared machinery holds more of the load. That is the personality of the project in one commit series: fewer special cases, same contract.

Btrfs: the features people actually run, on a root volume

Btrfs won the root-volume argument that Fedora settled in 2020 and SUSE settled years earlier, because the CoW feature set (snapshots, rollbacks via Snapper, transparent zstd compression, send/receive) is exactly what a desktop or a server root wants, and because being mainline means the distro hashes out the compatibility questions for you. Its honest limits are the ones nobody disputes: parity RAID is still marked not production-ready, the newer experimental work (remap-tree in kernel 7.0, block size greater than page size) is marked experimental in the project's own notes, and the raid-stripe-tree path to a fix is moving but has not arrived: the tree itself shipped in 6.7, and a June 2026 RFC builds write-hole-free RAID5 on top of it, posted explicitly as an early design review with RAID6 unimplemented.

That last paragraph is the real cost of Btrfs: you inherit only what mainline gives you, and where mainline is stalled, you are stalled too. On a mirror or a single device, in practice, nothing is stalled, and Btrfs is boring in the best sense.

OpenZFS: the most machinery, and the most discipline

OpenZFS is the storage engineering exercise, and the current low-level story has genuinely advanced: RAIDZ expansion (since 2.3) removed the old objection that a RAIDZ pool is frozen in time, Fast Dedup made deduplication practical for the first time, Direct IO got it out of the double-buffering argument, and the 2.4 line keeps sharpening the hybrid-pool story: ZIL blocks can now land on special vdevs when there is no dedicated SLOG, and specialsmallblocks handling extends to ZVOL writes, so more of a job's hot path can be steered onto fast media (special vdevs themselves date back years; 2.4 widened what may live on them). The deal you sign, again, is outside-the-kernel: your kernel gets version-bounded, your distro choice matters (Proxmox ships it natively, Ubuntu packages it properly, Debian needs elbow grease), and your storage stack will occasionally break in interesting ways as mainline moves underneath. None of that is a dealbreaker; it is just a testing obligation you must actually schedule rather than imagine.

Choose ext4 when

• The volume is boring on purpose. Boot partitions, single-disk system disks, scratch and cache volumes, any box whose integrity story is written by a lower layer. ext4 is the filesystem you configure once, back up on a schedule, and never think about again.
• Another layer already owns the features. When restic or borg is the checksumming layer and LVM-thin is the snapshot layer, ext4 underneath is simple, and stacking extra layers is how you get a storage stack nobody can debug at 2am.
• You have a workload that hates CoW. Fragmentation on churny writes (databases, VMs without a zvol, repeated rebuilds) is the classic problem; ext4 does not have it because it has no copy-on-write to fragment.

Choose Btrfs when

• You live in the Fedora or openSUSE world, or the root volume wants snapshots and rollbacks as an infrastructure service. Snapper plus the distro's tooling makes rollback-on-update a property of the machine, not a project.
• You want checksums, compression, send/receive, and snapshots in the mainline kernel, with zero licensing or compatibility management. It is mainline: kernel updates are the distro's problem, and that is worth real administrative money.
• Your data layout sits on mirrors, and you are honest about it. Mirror profiles and single-device setups are the production paths; RAID56 is not. Knowing exactly where that line is matters more here than any scrub benchmark.

Choose OpenZFS when

• Data loss costs more than administration. End-to-end checksummed, self-healing storage with redundancy, snapshots by schedule, and incremental send/receive backups are the whole product, and with RAIDZ expansion the old pool-is-frozen objection is gone.
• You are running a storage appliance, not a filesystem plus other services. Pooled disks, zvol-backed VM images, datasets with per-workload compression and record size, and NFS or SMB exports tuned per dataset all add up to a system coherent in a way a stack of LVM volumes never quite gets.
• You are on Proxmox, a NAS, or a homelab that treats checksummed data end to end as a requirement rather than a checkbox. Just budget the ARC memory and the kernel-coupling testing cycles as line items, because they are.

When none of them is the right answer

• The workload replaces the storage anyway. Swap, ephemeral CI scratch, and cache layers are fine as tmpfs or a raw discardable device with no filesystem at all.
• The data-integrity problem is sometimes better solved above. Object stores with end-to-end checksums verify their own payloads, and some databases checksum their own pages, but that is per engine and per setting, not a law: SQLite does not checksum database pages by default (page checksums require the optional checksum VFS shim), so bolting a checksummed filesystem under a database is a layering decision, not a redundant copy of the same mechanism. ZFS-on-root does not belong on this list at all: it is just ZFS, one of the three filesystems compared here, not a separate integrity layer.
• You need the real reliability story: backups, tested. This 3-2-1 backup walkthrough starts with why three copies are the floor, not the ceiling, and the restore drill review covers testing it so that it actually works when it matters. No filesystem choice substitutes for this.

The honest limits

• This is a concept comparison, not a benchmark. Measured performance depends on your disks, your kernel version, and your workload far more than on the filesystem's roadmap. I will not invent numbers that say otherwise.
• This is Linux-centric. OpenZFS on FreeBSD and the Illumos lineage is a real ecosystem with somewhat different dynamics; Btrfs is essentially Linux-only; ext4 is not the answer outside Linux in the same way. If your estate includes Solaris-descended gear, the ZFS story changes shape.
• These three move fast, at three different speeds. OpenZFS ships 2.x lines with compatibility windows; Btrfs and ext4 ride mainline. Every version and kernel note in this post was checked on October 24, 2026; reconfirm before you pin anything.
• Feature checklists are not the product. On day 2 what matters is scrub behavior, snapshot retention, fragmentation over years, and how well the tooling answers operational questions. Try the serious contenders on hardware you care about before a decision. If you are choosing where those volumes first go (a hypervisor, an immutable container OS), the Proxmox vs IncusOS comparison and the immutable node OS comparison are the adjacent decisions.

Versions checked

FAQ

Is Btrfs finally good for RAID6 in 2026?

No. The Btrfs documentation still marks RAID56 not production-ready. The raid-stripe-tree infrastructure meant to fix it did land (kernel 6.7, zoned mode first), and a June 2026 RFC series is building write-hole-free RAID5 on top of it, but that is an early design review, RAID6 is not implemented, and none of it is usable today. Use mirror profiles (RAID1, RAID1c3, the latter being three copies and still mirroring, not parity) if you want self-healing on Btrfs, or OpenZFS if you want parity RAID inside the filesystem.

Is OpenZFS still not in the mainline kernel?

Correct: the CDDL/GPL incompatibility is structural. OpenZFS remains a well-maintained out-of-tree project, currently at 2.4.4 with Linux 7.2 support and compatibility back to Linux 4.18. Distributions like Ubuntu and Proxmox ship it natively, which is the practical answer for most people who want it built into the install.

Does ext4 detect silent data corruption?

Not on data. ext4 checksums metadata and journal content, but file data reads back whatever the medium returns, with no checksum to catch silent rot. If that matters, run storage that actually verifies (Btrfs or OpenZFS scrub), or put a checksumming backup layer over it.

Is ZFS still better than Btrfs for NAS storage?

For multi-disk data storage with parity RAID, mostly yes: RAIDZ, plus the 2.3-era expansion story, is much more mature than Btrfs's documented not-production-ready parity profiles. For mirrored single-node setups, mainline Btrfs is competitive and simpler to administer. For root volumes and client workloads, the choice is genuinely close.

What do they cost?

All three are free and open source: ext4 and Btrfs under GPL, OpenZFS under CDDL. Money enters at the edges: the ARC RAM OpenZFS wants, the testing cycles its compatibility windows impose on your fleet, and the LVM or backup layers you add when ext4 is the base.

Further reading

• OpenZFS releases and changelogs: https://github.com/openzfs/zfs/releases
• OpenZFS 2.4.4 release notes (Linux 7.2 support): https://www.phoronix.com/news/OpenZFS-2.4.4-Released
• OpenZFS 2.3 with RAIDZ expansion and Fast Dedup: https://www.phoronix.com/news/OpenZFS-2.3-Released
• Btrfs kernel-by-version feature notes: https://btrfs.readthedocs.io/en/latest/Kernel-by-version.html
• Btrfs feature status, including the RAID56 verdict (read before creating an array): https://btrfs.readthedocs.io/en/latest/Status.html
• Linux 7.3 iomap improvements for ext4 and XFS: https://www.phoronix.com/news/IOmap-Linux-7.3-Faster
• ext4 kernel documentation: https://docs.kernel.org/admin-guide/ext4.html
• Our Proxmox vs IncusOS comparison (ZFS in the stack): https://systhoughts.com/posts/proxmox-vs-incusos
• Our 3-2-1 backup walkthrough: https://systhoughts.com/posts/3-2-1-backup-rule-not-enough-self-hosted-infrastructure

Which of the three runs your volumes, and what decided it: the boring reliability of ext4, the mainline pragmatism of Btrfs, or the appliance discipline of OpenZFS? If you migrated between them, tell me what you missed first. Drop it in the comments.

Until next time, keep your systems thoughtful.