ZFS vs Btrfs for a Home NAS: Which One Should You Run

Pick a side in ZFS vs Btrfs for a home NAS and you will find a forum thread that agrees with you. The comparison that matters is narrower than the usual one, because the differences that bite in a four-bay box at home are not throughput numbers. They are what each project’s own documentation says you are permitted to do: which redundancy profiles it will stand behind, whether you can add one disk or must add several, and whether you can ever take a disk back out.

How this comparison was put together

This is a documentation comparison, not a benchmark shootout. The claims below come from the Btrfs feature stability table, the Btrfs manual pages, the OpenZFS man pages for zpool-attach and zpool-remove, and the TrueNAS ZFS Primer. Nothing here is a figure from a test rig.

That is deliberate. Behind a 1 or 2.5 GbE link, both filesystems saturate the network on sequential work long before either becomes the bottleneck. What does not average out over five years is a redundancy profile whose own maintainers call it unstable, or a pool geometry you cannot undo.

The comparison table

	OpenZFS	Btrfs
Kernel integration	Out of tree; CDDL and GPLv2 cannot share a binary	Mainline Linux kernel
Parity RAID	RAIDZ1/Z2/Z3, supported	RAID5/6 marked unstable
Mirroring	N-way mirror vdevs	raid1 (2 copies), raid1c3 (3), raid1c4 (4), raid10
Add one disk	RAIDZ expansion since OpenZFS 2.3	btrfs device add while mounted
Remove a disk	Impossible if the pool holds a raidz vdev	btrfs device remove, profile permitting
Mixed disk sizes	A vdev uses its smallest member	Handled natively
Checksums	On by default, currently fletcher4	On by default (crc32c, others available)
Compression	compression=on selects lz4 when the feature is enabled	zstd, zlib, lzo

Where Btrfs genuinely wins

It is already there. Btrfs is in the mainline kernel. ZFS cannot be, because the CDDL and GPLv2 cannot be combined in one binary, though the OpenZFS licence page is clear that shipping it as a separate module or as source is fine. In practice: a DKMS build rebuilt against every new kernel, which is a recurring chore if you upgrade kernels casually.

You can reshape it while it is mounted. The volume management docs cover btrfs device add on a live filesystem, btrfs device remove, and btrfs balance with a convert filter to change data and metadata profiles independently. Mixed device sizes work, which matters if your disks arrived one at a time. ZFS has no equivalent: a mirror or RAIDZ vdev uses its smallest member and wastes the rest.

It is cheap on memory. Btrfs uses the ordinary page cache. There is no ARC to size and no zfs_arc_max to argue about. On an N100 mini-PC with 16 GB shared with containers, that is one less thing to tune.

Where ZFS genuinely wins

Parity RAID you can actually deploy. This is the whole ballgame for most home builds. The Btrfs RAID56 section is unusually blunt. An unclean shutdown can leave a stripe where some ranges and the parity are from the old write and some from the new, nothing tracks which is which, and no write journal exists. Full read-modify-write would close the hole at an unacceptable performance cost. The guidance is explicit: do not use raid5 or raid6 for metadata, use raid1 or raid1c3, and the feature “should not be used in production, only for evaluation or testing.”

ZFS carries no equivalent asterisk. Copy-on-write means a RAIDZ stripe is never partially overwritten in place; as the TrueNAS primer puts it, changes go to a copy rather than to the original blocks, so ZFS always writes to free space.

Mirrors mean what you think they mean. Btrfs raid1 keeps exactly two copies however many devices are in the filesystem. Five disks in Btrfs raid1 still tolerate one failure, not two; for more you ask for raid1c3 or raid1c4 explicitly. A three-way ZFS mirror survives two. Not wrong, but it surprises people.

Self-healing depends on owning the redundancy. Both filesystems checksum data and repair from a good copy, but only if they hold that copy themselves. The OpenZFS hardware guidance states the rule directly: a checksum failure is corrected by reconstructing the sector from the other disks, and this “cannot be done when a RAID controller handles the redundancy unless a duplicate copy is stored by ZFS.” The same logic applies to a Btrfs volume running the single profile on an array managed below it. It detects the corruption and has no copy of its own to fix it with. That is why ZFS wants disks passed through directly, as covered in our ZFS hardware requirements guide.

Expansion, in opposite directions

The old knock on ZFS, that you could not widen a RAIDZ vdev, went away with OpenZFS 2.3 in January 2025. The zpool attach man page describes the mechanics: allocated space is read from the existing disks and rewritten across the larger set, redundancy holds throughout, the expansion pauses if a disk fails mid-flight, and a pool-wide scrub runs at the end. The catch is that old blocks keep their old data-to-parity ratio, so a 5-wide RAIDZ2 expanded to six disks still stores existing data 3-wide with 2 parity, just spread wider. You get the space, not the retroactive efficiency.

What ZFS still will not do is shrink. zpool remove handles spares, cache, log, special and dedup devices, plus mirrored or non-redundant top-level vdevs, but only if the pool contains no top-level raidz or draid vdev at all. Add a RAIDZ vdev by mistake and it is there until you destroy the pool. Btrfs will let you remove a device and rebalance, which is the flexibility ZFS people quietly envy.

Both snapshot and replicate. ZFS snapshots are instant and initially free, and zfs send streams to a remote system that does not need a matching pool layout; Btrfs send/receive is marked OK. Read-only snapshots on a box the attacker cannot administer are one of the few things that survive a ransomware event, which is reason enough to follow general security coverage rather than treating the NAS as solved.

Which one to pick

Four or more disks, parity redundancy, this is your bulk storage: ZFS. RAIDZ2 on a single vdev, not RAIDZ1 if the drives are large. TrueNAS recommends 3 to 9 disks per vdev and advises against RAIDZ1 above 1 TiB per drive. Pick a distribution that ships ZFS packages so you are not building the module yourself. Our parity level guide covers the failure arithmetic.

Two disks, or an odd pile of mismatched drives you keep adding to: Btrfs. raid1 for data and metadata, add and remove devices as hardware turns up, and accept two copies as the ceiling unless you move to raid1c3.

Btrfs on an existing Synology or QNAP array: keep it. You get checksums and snapshots, the vendor tests that stack, and rebuilding it as a ZFS box is a weekend you will not get back.

The one configuration nobody should choose is Btrfs RAID5 or RAID6 for data that matters. Not because of a benchmark, but because the people who wrote it say not to.