Btrfs vs ZFS on Linux in 2026: Practical Winner, Technical Winner

· 10 min read

Btrfs is king on Linux. Not because it’s technically superior to ZFS in every dimension — it isn’t — but because it ships in the kernel, installs without friction, and integrates with every major distro’s tooling out of the box. In 2026, if you format a fresh Fedora, openSUSE, or Ubuntu Desktop installation, you’re running Btrfs by default. ZFS requires you to want it badly enough to fight the packaging.

That gap between “technically best” and “practically default” is the story of these two filesystems on Linux. Let’s dig into it honestly.

The licensing reality: CDDL vs GPL, and why it still matters

ZFS was born at Sun Microsystems under the Common Development and Distribution License (CDDL). The Linux kernel is GPLv2. The Free Software Foundation has stated clearly that CDDL and GPL code cannot be linked together in the same binary. This isn’t a theoretical concern — it’s the reason ZFS cannot ship as part of the Linux kernel.

In practice, this means:

  • Distros must ship ZFS as a separate DKMS module or pre-built package, rebuilding it every kernel update.
  • Canonical ships ZFS in Ubuntu’s installer (marked experimental since 24.04 LTS), having concluded that loadable kernel modules sidestep the linking restriction. That legal position has never been tested in court.
  • Fedora refuses to ship ZFS at all. Red Hat won’t touch it.
  • A February 2025 proposal to dual-license OpenZFS under CDDL + GPLv2 stalled because Oracle never responded and Linus showed zero interest in mainlining it.

The operational consequence: every kernel upgrade is a potential breakage point for ZFS users. DKMS rebuilds fail on new kernels before the ZFS module catches up. On Fedora, where kernels land fast, this is a recurring headache.

Btrfs, by contrast, lives in fs/btrfs/ inside the kernel tree. It gets the same review, the same CI, the same release cadence as everything else. When a kernel ships, Btrfs ships. No rebuild, no lag, no prayer.

Snapshot and rollback workflows

Both filesystems treat snapshots as first-class operations, but the ecosystem around them diverges sharply.

Btrfs: snapshots as a system feature

openSUSE has shipped Snapper-managed Btrfs snapshots for years. Every zypper transaction creates a pre/post snapshot pair. Boot into GRUB, pick a snapshot, roll back. Done.

Fedora is catching up — Fedora 42 now supports Snapper with DNF5 hooks and grub-btrfs entries, though it still requires manual setup rather than being default.

On the desktop, Timeshift gives you one-click rollback on any Btrfs-formatted system. The workflow is dead simple:

# Create a manual snapshot
sudo btrfs subvolume snapshot -r / /snapshots/pre-upgrade

# List snapshots
sudo btrfs subvolume list /

# Rollback: boot from snapshot, then move subvolumes
sudo mv /mnt/@root /mnt/@root.broken
sudo btrfs subvolume snapshot /mnt/@snapshots/pre-upgrade /mnt/@root

Incremental send/receive for offsite backup is equally straightforward:

# First full send
sudo btrfs send /snapshots/daily-2026-05-24 | ssh backup-host btrfs receive /backups/

# Subsequent incremental
sudo btrfs send -p /snapshots/daily-2026-05-24 /snapshots/daily-2026-05-25 \
  | ssh backup-host btrfs receive /backups/

ZFS: snapshots with more power, more ceremony

ZFS snapshots are instantaneous and cheap, and zfs send/receive is arguably more mature and better battle-tested at scale:

# Snapshot
zfs snapshot rpool/ROOT/ubuntu@pre-upgrade

# List
zfs list -t snapshot

# Rollback
zfs rollback rpool/ROOT/ubuntu@pre-upgrade

# Incremental replication
zfs send -i rpool/data@monday rpool/data@tuesday | ssh backup zfs receive tank/data

ZFS rollback is atomic and has been production-proven for two decades. The zfs send stream format is stable and well-documented. Tools like Sanoid/Syncoid automate retention and replication with policy-based cleanup.

The catch: none of this is integrated into distro installers or desktop tools the way Snapper is. You need to know ZFS. You need to set it up yourself. The tooling assumes you’re an operator, not a user.

Performance and memory behavior

Let me be direct: most Btrfs-vs-ZFS “benchmarks” online are synthetic garbage that tells you nothing about real workloads. But some patterns are consistent enough to state:

ZFS is memory-hungry by design. The ARC (Adaptive Replacement Cache) aggressively fills available RAM. On a 64 GB server this is a feature — hot data stays in RAM, repeat reads are instant. On a 4–8 GB laptop, it’s a problem. ZFS on low-memory machines feels sluggish, and tuning zfs_arc_max is the first thing every guide tells you to do.

Btrfs is lighter. It relies on the kernel’s page cache like any other filesystem. No dedicated caching layer to configure or fight with. On NVMe drives, this matters less — the storage is fast enough that ZFS’s caching provides diminishing returns.

NVMe-specific behavior: A 2025 benchmark from Nicholas Lyz and a reported OpenZFS issue showed ZFS underperforming Btrfs significantly on NVMe for database-like mixed workloads. ZFS’s write pipeline, designed for spinning rust and SLOG devices, doesn’t always map well to raw NVMe speed. OpenZFS 2.3’s Direct I/O support helps — it bypasses ARC for workloads that don’t benefit from caching — but it requires explicit opt-in.

Sequential reads at scale: ZFS still dominates when the ARC is warm and the dataset fits memory patterns. For large media files, VM images, or backup repositories where data is read repeatedly, ZFS’s caching architecture earns its RAM tax.

I won’t cite specific IOPS numbers because they depend too heavily on pool geometry, compression settings, record size, and whether the test was warmed up. If someone gives you a clean number, they’re probably lying or benchmarking something irrelevant to your workload.

Operational complexity

Scrub

Both filesystems scrub — verifying checksums and repairing corruption.

# Btrfs
sudo btrfs scrub start /
sudo btrfs scrub status /

# ZFS
sudo zpool scrub rpool
sudo zpool status rpool

ZFS scrub is more battle-tested and can auto-repair from redundant copies (copies=2 or RAIDZ). Btrfs scrub repairs data from RAID1 mirrors but cannot fix RAID5/6 parity inconsistencies introduced by write-hole scenarios.

Expansion

This is where ZFS caught up dramatically. Before OpenZFS 2.3 (January 2025), expanding a RAIDZ vdev was impossible — you had to add entire new vdevs. Now, RAIDZ expansion lets you add a single disk to an existing RAIDZ group:

zpool attach tank raidz1-0 /dev/sde

The “reflow” process redistributes data online — no downtime. Old blocks keep their original parity ratio; new writes use the wider stripe. It’s a long-awaited feature, though the expansion is slow and you should not remove the added disk once started.

Btrfs has always been flexible here. Adding and removing devices is trivial:

sudo btrfs device add /dev/sde /mnt/data
sudo btrfs balance start /mnt/data

You can convert between RAID profiles on a live filesystem:

sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/data

This operational flexibility — reshape on the fly, convert profiles without unmounting — remains one of Btrfs’s strongest practical advantages for small to mid-size deployments.

Recovery

ZFS’s recovery story is stronger. zpool import will find and assemble pools from raw disks regardless of what machine you plug them into. The uberblock redundancy (multiple copies at known offsets) makes ZFS pools remarkably resilient to metadata corruption.

Btrfs recovery is possible (btrfs rescue and btrfs restore exist) but less reliable in practice. Severe metadata corruption can make a Btrfs volume unrecoverable in situations where ZFS would still import. This is the trade-off for Btrfs’s more flexible metadata layout.

Ecosystem support

Distro defaults (2026)

  • Fedora: Btrfs default since Fedora 33 (2020). Snapshot integration improving. ZFS not available in repos.
  • openSUSE: Btrfs with Snapper since 2014. The gold standard for desktop rollback.
  • Ubuntu: Btrfs available, ext4 default for desktop. ZFS offered as experimental in the installer.
  • Debian: ext4 default. Neither Btrfs nor ZFS is highlighted.
  • NixOS: ZFS well-supported with declarative configuration.
  • Proxmox: ZFS recommended and default for VM storage.
  • TrueNAS: ZFS-native (OpenZFS 2.3 in TrueNAS 25.04).

Tooling and community

Btrfs has Snapper, Timeshift, btrbk, grub-btrfs, and the kernel maintainers fixing bugs on the same release cycle. Documentation lives at btrfs.readthedocs.io and is kept current.

ZFS has Sanoid/Syncoid, zrepl, zfs-auto-snapshot, and a deeply knowledgeable but smaller community. OpenZFS documentation is solid, and the openzfs/zfs GitHub is active.

The RAID5/6 elephant

As of kernel 7.0, Btrfs RAID5/6 remains gated behind CONFIG_BTRFS_EXPERIMENTAL. The official status marks it “unstable.” The write-hole problem — where a crash during a stripe write leaves parity inconsistent and scrub cannot correct it — has no fix. If you need parity RAID on Linux, ZFS’s RAIDZ is the only production-ready answer. Period.

Btrfs RAID1 and RAID10 are stable and production-proven. But if your use case requires parity redundancy (three disks, one parity), you must choose ZFS or use mdraid underneath.

Who should pick Btrfs, who should pick ZFS

Pick Btrfs if:

  • You run Fedora, openSUSE, or any distro where it’s the default and integrated into the update/snapshot lifecycle.
  • You want snapshots without thinking about it — Snapper and Timeshift just work.
  • Your machines have 4–16 GB RAM and you don’t want to fight the ARC.
  • You need to add/remove/resize disks flexibly without planning a pool topology in advance.
  • You’re running NVMe-only and don’t want ZFS’s caching overhead.
  • RAID1 or RAID10 meets your redundancy needs.
  • You want zero friction on kernel upgrades.

Pick ZFS if:

  • You run a storage server, NAS, or backup target where data integrity is the primary requirement.
  • You need RAIDZ1/Z2/Z3 parity redundancy that actually works.
  • Your machines have 32+ GB RAM and ZFS’s ARC will serve you rather than starve you.
  • You need proven replication workflows (zfs send/receive at scale).
  • You’re on Ubuntu, Proxmox, TrueNAS, NixOS, or FreeBSD where ZFS is well-packaged.
  • You can tolerate DKMS rebuilds and the occasional kernel-upgrade lag.
  • You’re running datasets large enough that ARC and L2ARC provide real performance gains.

Pick neither if:

  • You just need a fast, reliable filesystem with no snapshots: ext4 or XFS remain perfectly fine choices and carry less complexity.

What I would run in production today

On servers storing critical data — backup repos, database hosts, NAS appliances — I’d run ZFS without hesitation. RAIDZ2, ECC RAM, Sanoid for snapshot policy, zfs send to a replication target. The licensing friction is worth paying because ZFS’s data integrity guarantees are genuinely stronger, recovery is more reliable, and parity RAID actually works.

On workstations and general-purpose Linux boxes — Btrfs, full stop. Fedora ships it, Snapper manages it, kernel upgrades don’t break it. I get transparent compression (zstd), instant snapshots before every system update, and easy rollback when something goes wrong. The RAID1 profile on two NVMe drives gives me redundancy without the parity RAID question.

On container hosts and CI runners — Btrfs. The overlay/snapshot semantics play well with container runtimes, the memory footprint is predictable, and operational simplicity matters more than theoretical resilience when your workloads are ephemeral.

On a home NAS with 4–8 spinning disks — this is where I’d pause. ZFS RAIDZ2 is the technically correct answer because parity RAID works and data integrity is paramount. But if you’re on Fedora or don’t want the DKMS dance, Btrfs RAID1 on pairs of disks is a valid — if less space-efficient — alternative.

Final verdict

ZFS is the better filesystem by almost every technical measure that matters for data storage: stronger integrity guarantees, proven parity RAID, more resilient recovery, two decades of production hardening.

Btrfs is the better Linux filesystem by every practical measure that matters for running a system: kernel-native, zero licensing friction, flexible device management, lightweight resource footprint, deep distro integration.

The licensing wall isn’t getting torn down. Oracle won’t relicense, Linus won’t merge out-of-tree code, and the FSF won’t change its interpretation. So in 2026, the practical winner and the technical winner remain different filesystems — and for most Linux users, practical wins.

If your data’s survival is worth the operational tax of running out-of-tree kernel modules, choose ZFS. If your workflow demands integration, flexibility, and zero-friction upgrades, choose Btrfs. Both are defensible positions. Neither is wrong.

But if someone tells you there’s a single “best” filesystem — they haven’t run both in production.