Btrfs or ZFS — your data survives a disk crash, but only with the right filesystem

In 2026, Btrfs and OpenZFS 2.4 dominate advanced Linux storage. One lives inside the kernel, the other requires an out-of-tree module — and that single detail changes everything depending on whether you run a desktop, a NAS, or a server.

April 22, 2026. Linux kernel 7.1 shipped three weeks ago. OpenZFS 2.4.2 is the latest stable release, and the 2.4.0 series (March 2025) delivered the biggest feature drop in a decade. And the question every sysadmin eventually faces hasn’t changed in ten years: Btrfs or ZFS?

The answer is not about preference. It’s about what you’re protecting, and what you’re willing to lose.

Two philosophies, one promise

Btrfs and ZFS are both copy-on-write (COW) filesystems with snapshots, compression, checksumming, and integrated software RAID. Their shared promise: your data will never silently corrupt.

But they deliver on that promise through two radically different paths.

Btrfs has lived inside the Linux kernel since 2009. It’s maintained by kernel developers, evolves with every release, and requires zero external modules. It’s the default filesystem on Fedora since version 33 and SUSE Linux Enterprise since 15. It’s natively supported by systemd, modern bootloaders, and the entire Linux ecosystem.

OpenZFS is a separate project born from porting ZFS — the historic Sun Solaris filesystem — to Linux and FreeBSD. Its CDDL license is incompatible with the Linux kernel’s GPL: OpenZFS will never be merged into mainline. It must be compiled as an out-of-tree module (DKMS) and tracks kernel releases with a lag of a few weeks. Version 2.4.2 supports kernels 4.18 through 7.0, and 2.4.0 (March 2025) brought three major features: Fast Dedup, Direct I/O, and online RAID-Z expansion — adding a disk to an existing RAID-Z vdev without recreating it.

The deal-breaker: RAID maturity

This is where everything hinges.

Btrfs RAID1, RAID1C3, RAID1C4, and RAID10 are stable and marked OK in the official maturity matrix (kernel 7.1). Scrubbing, device replacement, and degraded mounts all work.

Btrfs RAID5/RAID6 remains unstable. The official documentation still marks it unstable as of April 2026 — the RAID5 write hole (silent corruption after a power loss on parity RAID) is not resolved. The btrfs(5) man page is unambiguous: “RAID56 provides no safeguards against the RAID5 write hole. You should not use RAID56 for anything but testing with throw-away data.”

This isn’t a bug being fixed. It’s an architectural problem identified since 2016.

ZFS RAID-Z (RAID-Z1, Z2, Z3) has been mature for over fifteen years. No write hole. No silent corruption on power loss. Data and parity stay consistent thanks to ZFS’s transactional COW model. And since OpenZFS 2.4.0, you can add a disk to an existing RAID-Z vdev — a feature even Oracle’s ZFS never had.

For a NAS or storage server, the verdict is clear: ZFS is the only reliable choice if you’re using parity RAID.

RAM, caching, and performance

ZFS needs RAM. Its ARC (Adaptive Replacement Cache) is the engine behind its performance: it caches the most frequently and recently read blocks in memory. The official recommendation is 8 GB minimum, and significantly more if you enable deduplication — each deduplicated block consumes roughly 320 bytes of RAM in the DDT (Dedup Table). The new Fast Dedup feature (2.4.0) reduces this footprint by journaling entries, but doesn’t eliminate it.

Btrfs uses Linux’s standard page cache. No dedicated cache, no disproportionate memory consumption. A desktop with 4 GB of RAM runs Btrfs without breaking a sweat. zstd compression (level 3 by default) is fast and effective — often faster than uncompressed writes on SSD.

For a desktop, Btrfs is the clear winner: lightweight, integrated, no surprises on the next apt upgrade. For a server with 32 GB of RAM, ZFS’s ARC puts that memory to work for exceptional read performance — that’s an advantage, not waste.

Native encryption

ZFS ships with native encryption (AES-256-GCM) at the dataset level. You can encrypt tank/documents without touching tank/media. Encrypted snapshots stay encrypted, even when sent via zfs send. It’s built-in, tested, and doesn’t depend on LUKS.

Btrfs has no encryption. You must use LUKS/dm-crypt underneath. It works, but you encrypt the entire block device — no per-subvolume granularity. If you want to unlock a specific subvolume at boot without exposing others, you can’t.

For a laptop or any server handling sensitive data, ZFS scores a clear point.

Snapshots and rollback: Btrfs wins

Btrfs has snapshot ergonomics that ZFS envies. With tools like Snapper, Timeshift, or btrbk, you set up automatic hourly snapshots, you can boot into a previous snapshot directly from GRUB, and rollback is trivial:

bash

# Snapshot before an upgrade
btrfs subvolume snapshot /mnt/@root /mnt/@root-pre-upgrade

# Rollback if it breaks
btrfs subvolume delete /mnt/@root
mv /mnt/@root-pre-upgrade /mnt/@root

On openSUSE and Fedora, this integration is native: every zypper or dnf transaction triggers an automatic snapshot. If the upgrade breaks the system, you reboot into the previous snapshot. This is the number one reason to use Btrfs on a desktop.

ZFS can do the same (zfs snapshot, zfs rollback), but bootloader integration is more complex and less widespread. On Ubuntu, ZFS root support has regressed — Canonical quietly removed the ZFS on root option from the installer in 2024.

Send/Receive: a draw

Both filesystems excel at incremental replication:

bash

# Btrfs
btrfs send -p @snap1 @snap2 | ssh backup btrfs receive /backup/

# ZFS
zfs send -i tank@snap1 tank@snap2 | ssh backup zfs recv backup/tank

In both cases, only the differences between snapshots are transferred. Remote replication is efficient, verified, and production-ready. A solid shared foundation for backup strategies.

The comparison table

CriterionBtrfs (kernel 7.1)OpenZFS 2.4.2Kernel integrationNative (GPL, mainline)Out-of-tree module (CDDL, DKMS)RAID1/RAID10OK (stable)OK (mature mirrors)RAID5/RAID6/RAID-ZUnstable (write hole)OK (mature RAID-Z1/Z2/Z3)Native encryptionNo (LUKS required)Yes (AES-256-GCM per dataset)Compressionzstd, lzo, zlibzstd, lzo, gzip, zleMemory cacheLinux page cacheDedicated ARCSnapshots + rollbackExcellent (Snapper, Timeshift)Excellent (less distro-integrated)Send/ReceiveYesYesDeduplicationOut-of-band (duperemove)Inline + Fast DedupMinimum RAM~2 GB~8 GB recommendedOnline RAID expansionYes (device add + balance)Yes since 2.4.0 (RAID-Z expansion)Bootloader integrationGRUB, systemd-bootManual configuration

The verdict

Use Btrfs if:

You run a Linux desktop or laptop (Fedora, openSUSE, Arch)
You want automatic snapshots before every system update
You don’t need RAID5/6 — you’re using a single disk, RAID1, or RAID10
You already encrypt with LUKS and don’t miss per-dataset granularity
You want a filesystem that survives an apt upgrade without DKMS recompilation

Use ZFS if:

You’re building a NAS or storage server with 3 or more disks
You need RAID-Z (parity with guaranteed integrity)
You want native encryption per dataset
You have 32 GB of RAM or more and want your cache to actually do something
You accept the kernel compatibility lag and DKMS recompilation

Do not use Btrfs RAID5/6 in production. As of April 2026, this mode is still unstable. If you need parity, switch to ZFS. If you want to stay on Btrfs, use RAID1 or RAID10 — or stack Btrfs on top of mdadm RAID6, but you’ll lose checksum-based self-healing.

The question isn’t “which one is better.” It’s “which one protects your data for your use case.” And the answer changes everything.

References

OpenZFS 2.4.2 Release Notes
Btrfs Status — kernel 7.1 — April 2026
btrfs(5) — RAID56 status and recommended practices — kernel 7.1
OpenZFS 2.4.0 Release Notes — March 2025
ArchWiki — Btrfs
ArchWiki — ZFS
OpenZFS FAQ