ZFS vs Btrfs on Linux

ZFS and Btrfs are both copy-on-write (COW) filesystems that promise data integrity, snapshots, and built-in RAID — but they come from different worlds, carry different trade-offs, and suit different workloads. Choosing between them without understanding those differences leads to surprises in production. This guide cuts through the noise with a direct feature comparison, licensing context, and a practical decision framework.

Background and Lineage

ZFS was created at Sun Microsystems, released as open source in 2005 under the CDDL license. After Oracle acquired Sun, the community forked it as OpenZFS, which now ships on Linux, FreeBSD, macOS, and illumos. OpenZFS 2.x is the version you use today.

Btrfs (B-tree filesystem) was started at Oracle in 2007 and merged into the mainline Linux kernel in 2009. It is licensed under the GPL and developed in-tree. Red Hat, SUSE, and Facebook (Meta) have all contributed heavily at different points.

Kernel Licensing: Why It Matters Practically

ZFS (CDDL) and the Linux kernel (GPL v2) are incompatible licenses. OpenZFS cannot be merged into the mainline kernel. On every distro, ZFS is delivered as an out-of-tree kernel module, either compiled from source via DKMS or shipped as pre-built binaries.

Btrfs is GPL, lives in-tree, ships with every standard kernel, and needs no extra packages. For environments where touching out-of-tree modules is forbidden — some enterprise security policies, certain cloud VM images, locked-down UEFI Secure Boot setups — Btrfs is the only choice.

Installing ZFS on Debian/Ubuntu (via the official ZFS-on-Linux packages):

sudo apt install zfsutils-linux zfs-dkms

On Fedora 39+ or RHEL 9 clones (requires the OpenZFS repository):

sudo dnf install https://zfsonlinux.org/fedora/zfs-release-2-5$(rpm --eval "%{dist}").noarch.rpm
sudo dnf install zfs

On Arch Linux:

sudo pacman -S zfs-dkms zfs-utils

Btrfs tools are already present on most distros; you only need the userspace utilities:

# Debian/Ubuntu
sudo apt install btrfs-progs

# Fedora/RHEL
sudo dnf install btrfs-progs

# Arch
sudo pacman -S btrfs-progs

Maturity and Stability

ZFS has over two decades of production use on Solaris and FreeBSD before it ever ran on Linux. Its RAID-Z implementation, checksumming engine, and ARC (Adaptive Replacement Cache) are battle-tested at extreme scale. Enterprise storage appliances from NetApp competitors, TrueNAS, and countless hyperscalers run OpenZFS.

Btrfs has a more uneven history. Its basic features — subvolumes, snapshots, compression, and single-device use — are stable and widely deployed. SUSE Linux Enterprise has shipped Btrfs as the default root filesystem since SLE 12. However, Btrfs RAID 5 and RAID 6 have carried known data-loss bugs for years and are still not recommended for production data as of kernel 6.x. For multi-disk redundancy with Btrfs, use RAID 1 or RAID 10 only.

Feature Comparison

Feature	ZFS (OpenZFS 2.x)	Btrfs (kernel 6.x)
Snapshots	Instantaneous, space-efficient	Instantaneous, space-efficient
Send/receive replication	Yes, mature (zfs send)	Yes (btrfs send), fewer options
Transparent compression	LZ4, GZIP, ZSTD, LZO	ZLIB, LZO, ZSTD
Inline deduplication	Yes (RAM-heavy; use carefully)	No (out-of-band only with external tools)
RAID	RAID-Z1/Z2/Z3, mirror, dRAID	RAID 1, RAID 10 (safe); RAID 5/6 (unsafe)
Encryption	Native dataset encryption (OpenZFS 2.0+)	No native encryption; use dm-crypt underneath
Quotas	Per-dataset, per-project	Per-subvolume, per-qgroup
Checksumming	End-to-end, all metadata and data	Metadata always; data checksums on by default
Pool/volume management	Integrated (zpools)	Relies on kernel device stack or LVM
Kernel integration	Out-of-tree DKMS module	In-tree, upstream kernel

Performance Characteristics

ZFS performance is dominated by RAM. The ARC caches filesystem data aggressively and defaults to using up to half of system RAM. On a server with 64 GB RAM, ZFS can be extraordinarily fast for read-heavy workloads. Add an SSD as an L2ARC read cache or a dedicated SLOG device for synchronous write acceleration. RAM-constrained systems (under 8 GB) should approach ZFS cautiously — the general recommendation is 1 GB RAM per 1 TB of storage, though modern OpenZFS is less demanding than the old 1 GB/TB rule suggested.

Btrfs has lower baseline overhead. It performs well on desktop hardware with limited RAM, and its ZSTD compression often yields better real-world throughput than raw uncompressed I/O when CPU is not the bottleneck. On NVMe-heavy systems with many small random writes, Btrfs COW can cause fragmentation over time; periodic btrfs balance and btrfs defragment operations mitigate this.

Snapshots and Replication in Practice

ZFS Snapshots

# Create a recursive snapshot of a dataset
sudo zfs snapshot -r tank/data@2025-01-15

# List snapshots
sudo zfs list -t snapshot

# Send an incremental stream to a remote host
sudo zfs send -i tank/data@2025-01-14 tank/data@2025-01-15 \
  | ssh backup-host sudo zfs receive backup/data

Btrfs Snapshots

# Create a read-only snapshot
sudo btrfs subvolume snapshot -r /data /data-snapshots/2025-01-15

# Send snapshot to a remote host
sudo btrfs send /data-snapshots/2025-01-15 \
  | ssh backup-host sudo btrfs receive /backup/data-snapshots/

ZFS send/receive tracks incremental differences through the pool's internal transaction log, making complex replication pipelines straightforward. Btrfs send works well for simple cases but lacks per-stream encryption and some filtering options that ZFS provides natively.

Enabling Compression

# ZFS: enable ZSTD compression on a dataset
sudo zfs set compression=zstd tank/data

# Verify
sudo zfs get compression,compressratio tank/data

# Btrfs: mount with ZSTD compression
sudo mount -o compress=zstd /dev/sdX /mnt/data

# Or set it persistently in /etc/fstab
# UUID=... /data btrfs compress=zstd 0 0

What to Choose

Use ZFS when:

• You need proven multi-disk RAID with self-healing (NAS, file servers, backup targets).
• You want native encryption + compression + dedup in one layer.
• You have sufficient RAM (8 GB minimum; 16 GB+ recommended for pools over 4 TB).
• You are building a TrueNAS, Proxmox, or similar appliance-style system.
• You need mature, auditable send/receive replication pipelines.

Use Btrfs when:

• You want snapshots and compression on a desktop or laptop with limited RAM.
• You cannot use out-of-tree kernel modules (policy, Secure Boot, embedded systems).
• Your distro defaults to it (SUSE/openSUSE, Fedora Workstation since F33) and you want full integration with tools like snapper.
• You are running single-disk or simple two-disk mirror setups where Btrfs RAID 1 is safe.
• You need a lightweight filesystem for containers or VMs where pool management overhead is undesirable.

Verification

# ZFS: confirm pool health and checksum error count
sudo zpool status -v tank

# Btrfs: run a scrub and check for errors
sudo btrfs scrub start /data
sudo btrfs scrub status /data

Both commands should report zero errors on healthy arrays. Schedule zpool scrub or btrfs scrub monthly via a systemd timer or cron job — silent data corruption only surfaces if you look for it.

Troubleshooting

ZFS module not loading after kernel update: DKMS should rebuild the module automatically, but if it fails, run sudo dkms autoinstall and check dmesg. On systems with Secure Boot and MOK enrollment, the new module may need re-signing.

Btrfs fragmentation and slowdowns: Heavy random-write workloads fragment COW files. Run sudo btrfs filesystem defragment -r -v -czstd /data during a maintenance window. For databases, consider placing the database files on a subvolume with nodatacow set.

ZFS pool imported read-only after unclean shutdown: This means the pool has an unfinished transaction. Run sudo zpool import -F tank to replay the log. Always confirm with zpool status before writing data.

Btrfs balance stuck or taking forever: Large balances on full or nearly-full volumes can stall. Ensure at least 10–15% free space before balancing, and use btrfs balance pause /data to safely pause and resume.