Both are copy-on-write filesystems with snapshots, checksums, compression, and multi-device support. Our ZFS and Btrfs guides cover each individually, and our ext4, Btrfs, and XFS comparison covers the wider field.

This is the head-to-head, because the two genuinely overlap and the choice is not obvious.

What copy-on-write buys you

Shared by both, and the reason to use either.

Nothing is overwritten in place. A modified block is written elsewhere and the metadata updated to point at it. A power loss mid-write leaves the old data intact rather than a half-written block.

Checksums on everything. Every block is verified on read. Silent corruption, where a disk returns wrong data without reporting an error, is detected rather than propagated into your backups.

Snapshots are nearly free. A snapshot references existing blocks and costs space only as data diverges.

Compression is usually a win. zstd costs a little CPU and frequently reduces both space and I/O, making things faster on spinning disks.

Neither ext4 nor XFS gives you the checksums or the snapshots, which is the real reason to accept the complexity of either.

Licensing, which drives everything else

Btrfs is in the mainline kernel. It is there, it works, it needs nothing installed.

ZFS is not, and cannot be. The CDDL licence is considered GPL-incompatible by the kernel community, so ZFS on Linux ships as an out-of-tree module.

sudo apt install zfs-dkms zfsutils-linux
dkms status | grep zfs

The practical consequences are real:

It rebuilds on every kernel update through DKMS. When that fails, your pool does not import, and if root is on ZFS the machine does not boot.

It lags new kernels. OpenZFS must be updated for each kernel release, so early adopters of a new kernel wait. VirtualBox 7.2.18 shipping Linux 7.3 support ahead of the kernel is the same problem in a different package.

Some distributions make it awkward. Ubuntu ships it; others require third-party repositories.

If you want a filesystem that is simply present and never breaks on update, that is a point for Btrfs and it is not a small one.

RAID, where they differ most

This is the decisive difference for multi-disk systems.

Btrfs

RAID 0, 1, and 10 are stable and well-tested.

RAID 5 and 6 are not. There is a write hole, and the Btrfs documentation itself advises against production use. This has been the situation for years.

# fine
mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc

# do not
mkfs.btrfs -d raid5 -m raid5 /dev/sdb /dev/sdc /dev/sdd

If you want parity RAID under Btrfs, the workable approach is Btrfs on top of mdadm. You keep checksums and snapshots and lose Btrfs’s ability to self-heal from a good copy, because it no longer knows where the redundancy is.

Btrfs’s compensating strength: devices can be added and removed freely.

sudo btrfs device add /dev/sdd /mnt/data
sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/data
sudo btrfs device remove /dev/sdb /mnt/data

Add one disk. Change RAID level in place. Remove a disk while mounted. For a home setup growing one disk at a time, that flexibility is worth a great deal.

ZFS

RAIDZ1, RAIDZ2, and RAIDZ3 are mature, well-understood, and used at serious scale.

sudo zpool create tank raidz2 /dev/sd{b,c,d,e,f,g}
sudo zpool status tank
sudo zpool scrub tank

ZFS’s historical limitation was rigidity: you could not add a disk to an existing RAIDZ vdev, only add another whole vdev. That is the single most cited complaint, and RAIDZ expansion now exists in recent OpenZFS. It is newer than the rest of the codebase, which is worth weighing on data you care about.

Memory

The “1GB of RAM per TB” guidance follows ZFS around and is mostly wrong as stated.

That figure applies to deduplication, which is memory-hungry and which most people should not enable. Dedup needs a table held in RAM proportional to the data, and without enough it degrades badly.

zfs set dedup=off tank    # the correct default

Without dedup, ZFS runs comfortably on modest memory. What it does do is use free memory for ARC, its cache, which can look alarming:

arc_summary | head -20
cat /proc/spl/kstat/zfs/arcstats | grep -E '^size|^c_max'

ARC is reclaimable under pressure, so this is not a leak. It is the same confusion our free command guide covers for page cache, and you can cap it:

echo "options zfs zfs_arc_max=4294967296" | sudo tee /etc/modprobe.d/zfs.conf

Btrfs has no equivalent cache and uses less memory, which matters on a small VPS.

Snapshots and send/receive

Both do this well and it is one of the strongest arguments for either.

# ZFS
sudo zfs snapshot tank/data@$(date +%F)
sudo zfs send -i tank/data@yesterday tank/data@today | ssh host zfs receive backup/data

# Btrfs
sudo btrfs subvolume snapshot -r /mnt/data /mnt/snapshots/$(date +%F)
sudo btrfs send -p /mnt/snapshots/yesterday /mnt/snapshots/today | ssh host btrfs receive /backup

Incremental send transfers only changed blocks, which is what Incus uses for near-live container migration on both filesystems.

ZFS’s tooling here is more polished, with zfs-auto-snapshot and sanoid/syncoid being genuinely good. Btrfs has snapper and btrbk, which are fine.

Neither replaces a real backup. Snapshots on the same pool protect against mistakes, not against the pool dying. Our restic and Borg comparison covers what does.

Failure behaviour

ZFS degrades predictably. A failing disk is marked, the pool stays online, zpool status tells you plainly what is wrong. Its recovery tooling is mature and the community knowledge base is deep.

Btrfs has improved considerably and is still the one with a reputation. Its btrfs check --repair carries a warning telling you not to run it without advice, which is honest and not reassuring. A full Btrfs filesystem can become difficult to recover, because freeing space on a copy-on-write filesystem requires writing.

btrfs filesystem usage /mnt/data    # not df, which lies on Btrfs

Watch that. df reports misleading numbers on Btrfs because of how metadata and data allocation work, and a filesystem showing free space can still fail writes.

Choosing

Btrfs for a laptop or workstation, for a root filesystem where snapshot-and-rollback before updates is the goal, for a simple mirror, and where you want devices added over time. KDE Linux adding automatic snapshots and aerynOS’s installer work reflect that it is becoming the desktop default.

ZFS for a NAS, for anything with parity RAID, for large arrays, and where the maturity of the recovery tooling matters more than kernel integration.

Either for a single disk where you mainly want checksums and snapshots.

Neither if you want the simplest thing that works and have real backups. ext4 or XFS are excellent, fast, and boring, and boring has value.

The honest summary: ZFS is the better filesystem and Btrfs is the more convenient one. Which of those matters more depends on whether you are protecting a large array or a laptop.

Frequently Asked Questions

Is ZFS or Btrfs better?

ZFS is more mature for multi-disk arrays and has a stronger reliability record at scale. Btrfs is in the mainline kernel with no licensing friction and handles flexible single-disk and mirrored setups well. For a NAS with many disks ZFS is the safer choice, and for a laptop or a simple server Btrfs is usually the more convenient one.

Why is ZFS not in the Linux kernel?

ZFS is licensed under the CDDL, which the kernel community considers incompatible with the GPL. The practical result is that ZFS ships as an out-of-tree module built through DKMS, so it must rebuild on every kernel update and can lag new kernel releases.

Is Btrfs RAID 5 and 6 safe to use?

No. Btrfs RAID 5 and 6 have known issues including a write hole, and the documentation itself advises against production use. Btrfs RAID 0, 1, and 10 are considered stable. For parity RAID on Btrfs, the usual approach is Btrfs on top of mdadm rather than its native parity modes.

Does ZFS really need huge amounts of RAM?

The one gigabyte per terabyte guidance is widely repeated and applies mainly to deduplication, which most people should not enable. ZFS runs fine on modest memory without dedup, though its ARC cache will use whatever is available, which can look alarming in free output until you understand it is reclaimable.

Can I add a single disk to an existing ZFS pool?

Historically no, which was ZFS’s best-known limitation. RAIDZ expansion now exists in recent OpenZFS releases, and it is newer than the rest of the codebase. Btrfs has always allowed adding and removing devices freely followed by a rebalance, which is its main practical advantage for home use.

Do I need ECC memory for ZFS?

It is strongly recommended and not strictly required. ZFS checksums data on disk, and it cannot detect corruption that happens in memory before the checksum is computed. This is true of every filesystem, so ECC is good practice generally rather than a ZFS-specific requirement.