Pick up any discussion about Linux storage and you'll find the same two names circling each other: Btrfs and ZFS. Both are copy-on-write filesystems. Both offer snapshots, checksums, compression, and redundancy. Both have passionate defenders and equally passionate critics. And in 2026, both are mature enough that the "which one is ready?" argument has largely run its course.
So why does the debate persist? Because the two filesystems solve overlapping problems in fundamentally different ways, and the right answer depends entirely on what you're building. A laptop running Fedora has different needs than a 24-bay storage server running TrueNAS. A container host has different priorities than a workstation with full-disk encryption requirements.
This article cuts through the noise. We'll compare Btrfs and ZFS across architecture, data integrity, RAID, snapshots, compression, encryption, performance, and management. We'll examine real use cases and debunk the myths that refuse to die. By the end, you'll have a clear framework for choosing between them—or for knowing when the choice doesn't matter much at all.
Key Takeaway: Btrfs and ZFS are both production-ready in 2026, but they target different workloads. Btrfs favors flexibility and tight Linux integration; ZFS favors maximum reliability and enterprise-grade features.
Btrfs (pronounced "butter FS," short for B-tree filesystem) was originally developed at Oracle, with Chris Mason leading the effort. It was merged into the mainline Linux kernel in version 3.0, back in 2011. Since then, development has been driven by the Linux community, with significant contributions from SUSE, Facebook (now Meta), and individual kernel developers.
The core design goal was ambitious: bring ZFS-class features to Linux without the licensing headaches. That meant copy-on-write, checksums, snapshots, subvolumes, RAID, and compression—all built into the kernel itself. No external modules, no DKMS rebuilds after kernel upgrades, no licensing friction.
Btrfs is the default filesystem on Fedora Workstation (since version 33 in 2020) and has been the default on openSUSE since 2014. It's also widely used in embedded systems, container hosts, and anywhere snapshots and rollbacks are valuable.
ZFS was created at Sun Microsystems for Solaris in 2001 and quickly became the gold standard for enterprise storage. When Oracle acquired Sun in 2010, the open-source community forked the code into what became OpenZFS. Today, OpenZFS is actively maintained and runs on Linux, FreeBSD, and illumos.
Here's the catch: ZFS is licensed under the CDDL (Common Development and Distribution License), which is incompatible with the GPL that governs the Linux kernel. This means ZFS cannot be merged into the mainline kernel. On Linux, it runs as an out-of-tree kernel module, typically installed via DKMS or distribution-provided packages.
That licensing conflict isn't just a legal footnote. It has real consequences: kernel upgrades can break ZFS until the module is rebuilt, and some distributions (notably those with strict free-software policies) don't ship ZFS at all.
Despite their different lineages, Btrfs and ZFS share a common foundation:
These shared features are why the two are so often compared. The differences lie in how they implement them—and where they fall short.
Key Takeaway: Btrfs is in-kernel and Linux-native; ZFS is an out-of-tree module with a licensing conflict. Both share CoW, checksums, snapshots, and compression as core features.
In a traditional filesystem like ext4, modifying a file means overwriting its existing blocks. If the system crashes mid-write, you can end up with a corrupted file. Copy-on-write changes this: when you modify data, the filesystem writes the new version to unused blocks, then updates the metadata pointer to reference the new data. The old blocks remain intact until the transaction commits.
This design has two big benefits. First, it makes snapshots nearly free—a snapshot is just a reference to the old metadata tree. Second, it protects against partial writes: if power fails, the filesystem either sees the old data or the new data, never a mix.
Both Btrfs and ZFS use CoW, but ZFS implements it through a Merkle tree structure, where each block's checksum is stored in its parent block, all the way up to the uberblock at the root. This creates a verifiable chain of trust from the root to every leaf.
Silent data corruption—sometimes called bit rot—is the scenario where data on disk changes without any error being reported. A cosmic ray flips a bit, a drive's firmware misreports a write, a cable introduces noise. Traditional filesystems have no way to detect this. You only find out when you try to read the file and it's garbage.
Both Btrfs and ZFS address this with checksums. Btrfs uses CRC32C by default, with options for xxHash, SHA256, and BLAKE2. ZFS uses Fletcher4 for metadata and supports SHA256, Skein, and Edon-R for data.
When a checksum mismatch is detected, the filesystem knows the data is bad. If redundancy is available—a mirror or parity—it can fetch a good copy and repair the bad one. This is the core of what makes both filesystems "self-healing."
Here's where the two diverge in practice. Both detect corruption. Both can repair it if redundancy exists. But the reliability of that repair depends on the RAID implementation.
ZFS's RAID-Z is designed from the ground up to work with checksums. When a block fails its checksum, ZFS knows exactly which disk in the vdev should have the correct copy and reads from there. The variable stripe width of RAID-Z means there's no fixed parity layout to get out of sync.
Btrfs's RAID1 and RAID10 also work well with checksums—if one copy is bad, the filesystem reads the other. But Btrfs RAID5/6 has a known problem: the write hole. If power fails during a write to a degraded array, parity can become inconsistent, and the filesystem may not be able to tell which copy is correct. The Btrfs documentation explicitly warns against RAID5/6 in production.
Key Takeaway: Both filesystems detect corruption via checksums and can repair it with redundancy. ZFS RAID-Z handles this reliably; Btrfs RAID5/6 does not.
Both filesystems support scrubbing—a process that reads all data, verifies checksums, and repairs any errors found. On Btrfs, btrfs scrub start /mountpoint. On ZFS, zpool scrub poolname.
Scrubbing is essential for long-term data integrity. It catches corruption before it spreads and gives you early warning of failing drives. A monthly scrub is a reasonable baseline for most systems.
Btrfs supports RAID0 (striping), RAID1 (mirroring), RAID10 (striped mirrors), and RAID5/6 (parity). RAID0 and RAID1 are stable. RAID10 is stable. RAID5/6 is not.
The write-hole problem is fundamental: when writing to a parity RAID array, the data and parity updates aren't atomic. If the system crashes between writing data and writing parity, the array is left in an inconsistent state. Traditional RAID controllers solve this with battery-backed write caches or journaling. Btrfs has no such mechanism for RAID5/6.
As of 2026, the Btrfs status page still lists RAID5/6 as unstable for metadata and parity. The recommendation is simple: don't use it.
ZFS takes a different approach. RAID-Z1, RAID-Z2, and RAID-Z3 provide single, double, and triple parity respectively. Unlike traditional RAID5/6, RAID-Z uses variable stripe width: each stripe is sized to fit the data being written, and parity is calculated per-stripe. This eliminates the write hole entirely.
RAID-Z2 can survive two simultaneous disk failures per vdev. RAID-Z3 can survive three. For large arrays, this matters—the more disks you have, the higher the chance of multiple failures during a rebuild.
ZFS also supports mirrors (equivalent to RAID10) and striped mirrors, which are often preferred for performance-critical workloads.
Key Takeaway: Btrfs RAID5/6 is not production-ready due to the write hole. ZFS RAID-Z1/2/3 avoids this problem entirely and is the better choice for parity RAID.
Btrfs organizes data into subvolumes—independently mountable filesystem trees that share the same underlying storage pool. A subvolume can be snapshotted, and the snapshot is writable by default. This makes Btrfs snapshots flexible: you can boot into a snapshot, modify it, and even roll back to it.
Tools like Timeshift and snapper leverage this for automatic system snapshots. On Fedora and openSUSE, you get automatic rollback capability out of the box—if an update breaks your system, you can boot into a previous snapshot and restore.
ZFS uses datasets instead of subvolumes. A dataset is a filesystem with its own properties (compression, quotas, mount points). Snapshots in ZFS are always read-only. To modify a snapshot, you clone it—creating a new writable dataset that shares blocks with the snapshot.
This read-only design is deliberate: it prevents accidental modification of snapshot data. For backup and replication, it's ideal. For desktop rollback, it's slightly less convenient than Btrfs's writable snapshots, though tools like zfs rollback handle the common cases.
Both filesystems support send/receive for efficient replication. You can send a snapshot to another system, either as a full copy or as an incremental update from a previous snapshot.
Btrfs: btrfs send /snapshot | btrfs receive /backup
ZFS: zfs send pool/dataset@snap | zfs receive backup/dataset
Both work well. ZFS's send/receive is more mature and supports features like compressed streams and resumable transfers. Btrfs's implementation is solid but has fewer bells and whistles.
Key Takeaway: Btrfs snapshots are writable by default and integrate well with desktop rollback tools. ZFS snapshots are read-only, which is safer for backup workflows and replication.
Btrfs supports three compression algorithms: zlib, lzo, and zstd. Compression can be set per-file (with chattr +c) or per-subvolume (with mount options). Zstd is generally the best choice in 2026—it offers a good balance of speed and ratio.
One caveat: Btrfs compression is applied at write time. Existing data isn't retroactively compressed unless you rewrite it. Tools like btrfs defragment -c can help, but they're not always practical on large datasets.
ZFS supports lz4, zstd, and gzip, set per-dataset. Lz4 is the default and is extremely fast—often faster than uncompressed I/O because it reduces the amount of data written to disk. Zstd offers better compression ratios at slightly lower speed.
Like Btrfs, ZFS compression applies to new writes. Changing the compression algorithm on an existing dataset affects only new data unless you rewrite it.
This is one of the clearest differentiators. ZFS has native encryption since OpenZFS 0.8.0, using AES-256-GCM. It supports passphrase, raw key, and PKCS#11 key formats. Encryption is per-dataset, and you can encrypt the root dataset to protect everything.
Btrfs has experimental encryption support, but it's not recommended for production. The practical approach for Btrfs users is LUKS (Linux Unified Key Setup)—encrypt the underlying block device, then put Btrfs on top. This works well but has limitations: LUKS encrypts the whole device, so you can't have per-subvolume encryption, and replication of encrypted snapshots requires decrypting first.
Key Takeaway: ZFS has mature native encryption. Btrfs relies on LUKS, which is effective but less flexible for per-dataset encryption and encrypted replication.
ZFS uses the Adaptive Replacement Cache (ARC), which aggressively caches data in RAM. By default, ZFS can consume up to 50% of system memory for ARC. On systems with 8GB or less, this can cause pressure. You can limit ARC size with the zfs_arc_max module parameter, but tuning is often necessary.
Btrfs has a much smaller memory footprint. It uses page cache like any other Linux filesystem and doesn't have a separate cache layer. On memory-constrained systems, Btrfs is the better choice.
Both filesystems use CPU for checksums and compression. ZFS's default checksum (Fletcher4) is fast; Btrfs's CRC32C is also fast. Enabling stronger checksums (SHA256, BLAKE2) increases CPU usage on both.
Compression is where CPU matters more. Lz4 and zstd are both fast enough that the I/O savings usually outweigh the CPU cost, especially on NVMe. Gzip is slower and rarely worth it unless space is extremely tight.
Key Takeaway: ZFS uses more memory (ARC) but offers strong caching. Btrfs is lighter on RAM. Both perform well on modern hardware; workload and tuning matter more than the filesystem choice.
Btrfs is in the mainline kernel. If your distribution ships a recent kernel, you have Btrfs. No installation, no modules, no rebuilds after kernel upgrades.
ZFS requires either DKMS (which rebuilds the module on kernel updates) or distribution-provided kernel modules. On Ubuntu, apt install zfsutils-linux handles it. On Fedora, you need the zfs-release repository. On distributions that don't ship ZFS, you're on your own.
Btrfs is the default on Fedora Workstation and openSUSE. Ubuntu offers ZFS as a root filesystem option in the installer. Debian supports both. Arch supports both but defaults to ext4.
For desktop users, Btrfs is the path of least resistance. For server users, both are viable, but ZFS requires more planning.
Btrfs supports online shrinking—you can reduce the size of a filesystem while it's mounted. This is useful for virtual machines and containers where you need to reclaim space.
ZFS does not support shrinking a pool. You can add devices, replace devices, and grow the pool, but you cannot remove a vdev or shrink the pool without destroying and recreating it. This is a significant limitation for some workflows.
Btrfs tools: btrfs command, btrfs-progs package, integration with snapper, Timeshift, and distribution installers.
ZFS tools: zpool, zfs commands, zfsutils-linux package, integration with sanoid, syncoid, and TrueNAS.
Both have mature tooling. ZFS's ecosystem is more enterprise-focused; Btrfs's is more desktop-friendly.
Key Takeaway: Btrfs is easier to install and manage on Linux, with in-kernel support and online shrink. ZFS requires more setup and cannot shrink pools, but offers a richer enterprise toolset.
Choose Btrfs. It's the default on Fedora and openSUSE, requires no extra setup, and integrates with Timeshift and snapper for automatic rollbacks. Compression and snapshots work out of the box. ZFS on a laptop is possible but adds complexity and memory overhead.
Either works. Btrfs RAID1 is simple and reliable. ZFS mirrors or RAID-Z1 are also solid. If you need native encryption, ZFS has the edge. If you want easy expansion and online shrink, Btrfs is more flexible.
Choose ZFS. RAID-Z2 or RAID-Z3 provide reliable parity RAID without the write hole. Native encryption, quotas, and send/receive are mature. This is where ZFS shines.
Btrfs is often the better choice. Subvolumes map naturally to container storage, and snapshots are writable, which simplifies cloning. ZFS datasets also work, but the read-only snapshot model adds a step.
ZFS if you need native encryption. ZFS's AES-256-GCM is mature and supports per-dataset keys. Btrfs users should use LUKS, which is effective but less flexible for per-subvolume encryption and encrypted replication.
Key Takeaway: Btrfs for desktops, laptops, and container hosts. ZFS for large servers, enterprise storage, and native encryption requirements.
This was true in 2015. It's not true in 2026. Btrfs is stable for RAID0, RAID1, RAID10, and single-disk use. The only unstable feature is RAID5/6, which is well-documented. Fedora and openSUSE ship it by default.
No. ZFS is faster in some workloads (large sequential reads with ARC caching) and slower in others (parity RAID writes). Btrfs is often faster on NVMe and with many small files. Performance depends on workload and tuning.
Not without a licensing change. The CDDL and GPL are incompatible. This has been debated for over a decade and won't change soon.
Btrfs has experimental encryption, but it's not recommended for production. The practical solution is LUKS, which works well but isn't native.
There's no in-place conversion. You back up your data, create the new filesystem, and restore. Plan accordingly.
Key Takeaway: Most criticisms of Btrfs date from its early years. Most praise for ZFS ignores its licensing and memory overhead. Evaluate both on current facts.
Some users run Btrfs on their desktop and ZFS on their NAS. Others use ZFS for bulk storage and Btrfs for the root filesystem. There's no rule that says you have to pick one.
Looking ahead: Btrfs development continues, with ongoing work on RAID5/6 stability and encryption. OpenZFS 2.3 brought performance improvements and better NVMe support. The licensing conflict remains unresolved, but both filesystems are actively maintained and unlikely to disappear.
Key Takeaway: There's no universal winner. Choose Btrfs for flexibility and Linux integration; choose ZFS for reliability and enterprise features. Many users benefit from running both.
Which filesystem is better for a Linux desktop in 2026? Btrfs. It's the default on Fedora and openSUSE, requires no extra setup, and integrates with Timeshift and snapper for automatic rollbacks. ZFS works but adds complexity and memory overhead.
Can I use ZFS as my root filesystem on Linux? Yes. Ubuntu offers ZFS as a root filesystem option in its installer. Other distributions require manual setup. The main caveat is that kernel upgrades require rebuilding the ZFS module.
Is Btrfs RAID5/6 safe to use? No. The write-hole problem remains unresolved, and the Btrfs documentation explicitly warns against RAID5/6 in production. Use RAID1 or RAID10 instead.
Does ZFS support encryption? Yes. Native encryption with AES-256-GCM has been available since OpenZFS 0.8.0. It supports passphrase, raw key, and PKCS#11 key formats.
Which filesystem has better data integrity? Both are excellent. ZFS has a slight edge in parity RAID scenarios due to RAID-Z's design. Btrfs is equally good for RAID1 and RAID10.
Can I shrink a ZFS pool? No. ZFS does not support shrinking a pool. You can add or replace devices, but you cannot remove a vdev or reduce pool size without recreating it.
Which filesystem is more memory-hungry? ZFS. The ARC can consume up to 50% of system memory by default. Btrfs uses the standard page cache and has a much smaller footprint.
Are snapshots writable in Btrfs and ZFS? Btrfs snapshots are writable by default. ZFS snapshots are always read-only; to modify one, you clone it.
Which filesystem is better for large storage servers? ZFS. RAID-Z2 and RAID-Z3 provide reliable parity RAID, and native encryption and send/receive are mature. Btrfs is viable for smaller servers but lacks a reliable parity RAID option.
Is Btrfs stable in 2026? Yes, for RAID0, RAID1, RAID10, and single-disk use. RAID5/6 remains unstable. Btrfs is production-ready for most workloads outside of parity RAID.
Ready to choose your filesystem? Share your setup and get advice from the community, or dive deeper into the official Btrfs and OpenZFS documentation to make an informed decision.