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

For a home NAS, pick ZFS when you want parity RAID (RAIDZ1/2/3) on four or more matched disks, and Btrfs when you run two-disk mirrors or a mixed pile of drives you keep adding to and removing. Btrfs RAID5/6 is still marked unstable by its own developers as of Linux 7.2, and that settles most builds.

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 and tuning guides, the Linux md documentation, Unraid’s storage docs 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

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.

Btrfs vs ZFS RAID 1: how the mirrors differ

Both survive one dead disk out of two, and both can turn a lone disk into a mirror while the data stays online. They part ways on extra copies, on failure handling and on one bad default.

Copies and space. A ZFS mirror of N disks “can withstand N-1 devices failing”, per zpoolconcepts(7). The mkfs.btrfs profile table lists raid1 at 50% space utilisation, raid1c3 at 33% and raid1c4 at 25%, and the status table marks all the Btrfs mirror profiles OK for stability. On two disks, mixed sizes buy Btrfs nothing: the volume management docs show a 50 GiB plus 100 GiB pair giving at most 50 GiB of RAID1 space, the same as a ZFS mirror.

When a disk dies. ZFS marks the mirror DEGRADED (“sufficient replicas exist to continue functioning”) and keeps serving files until you replace the failed disk. Btrfs needs the degraded mount option, off by default, to mount with a device missing. The btrfs(5) manual then recommends balancing chunks with unwanted profiles, and the volume management guide prefers btrfs device replace over a balance that may write new chunks onto the failing device.

Reads. The OpenZFS workload tuning guide says read IOPS on mirrors scale with the number of drives in each mirror; Btrfs says its parallel mirror reads can be optimized further.

The default that catches people. mkfs.btrfs across several disks gives raid1 metadata but single data unless you pass -d. That has been the default since btrfs-progs 5.8 (raid0 before it), and it leaves your files with no second copy. The commands, from zpool-create, zpool-attach and the Btrfs guides:

On ZFS the attached disk starts resilvering immediately and any running scrub is cancelled.

ZFS vs Btrfs vs traditional RAID: do they replace mdadm?

Yes for ZFS, and for Btrfs only when you mirror. ZFS should see raw disks: its hardware guide says “Hardware RAID controllers should not be used with ZFS.” Btrfs replaces mdadm cleanly for raid1, raid1c3 and raid10, but its parity modes are unstable, so parity-protected Btrfs normally means Btrfs layered on md RAID5/6, inheriting md’s weaknesses.

The main one is the parity write hole. The Linux md documentation says an unclean shutdown can leave stripes where “data and parity don’t match”, and a further crash before the resync completes risks real corruption. A journal device closes the hole until that cache disk fails. OpenZFS expects hardware RAID 5/6 to almost certainly suffer partial stripe writes, which RAIDZ avoids by design through copy-on-write.

Stacking also splits the job in two, as the self-healing point above explains. Btrfs on a single device does default metadata to DUP, so metadata can still repair itself; file data in the single profile can only be flagged.

Btrfs vs ZFS performance: which is faster?

Neither is faster across the board. On a home NAS the gap comes from layout and tuning more than the filesystem: ZFS mirrors beat RAIDZ on small random I/O, RAIDZ beats mirrors on sequential writes, and the Btrfs status table rates its own mirror profiles only “mostly OK” for performance, with parallel mirror reads still to be optimized.

A shootout on one SSD with default mount options measures a desktop, not a NAS. ZFS datasets default to a 128K recordsize that the OpenZFS guide expects you to tune per dataset, and the differences live in those per-workload settings:

Think twice before the Btrfs fix. The btrfs(5) manual says in-place updates “improve performance for workloads that do frequent overwrites”, but nodatacow “implies nodatasum, and disables compression”, stripping checksums from exactly the VM disks and databases where you want them. ZFS keeps checksumming and changes the record size instead. Per-dataset compression is covered in our LZ4 vs zstd comparison, and ARC limits in the ARC sizing 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 can always take out hot spares, cache and log devices, but a top-level data vdev (mirror, single disk, special or dedup) can be removed only if the pool contains no top-level raidz or draid vdev, all top-level vdevs share one ashift, and encryption keys are loaded. 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.

Unraid ZFS vs Btrfs: which should your pools use?

On Unraid, use ZFS for a pool of matched drives where you want RAIDZ parity, and keep Btrfs, the default, for cache pools built from mismatched SSDs. Leave array disks on XFS, which Unraid’s docs recommend for most array users, because Unraid’s own parity already protects them.

ZFS pools arrived in Unraid 6.12.0 (14 June 2023) with raid0, mirror and raidz1/2/3 profiles. Unraid 7.2.0 (29 October 2025) added one-drive-at-a-time expansion of single-vdev RAIDZ pools from the web GUI; 7.1.x needed the command line. Two-device ZFS pools default to a mirror, so pick RAIDZ1 at creation if you plan to grow. Unraid caps the ARC at 1/8 of installed RAM (override in config/modprobe.d/zfs.conf), and its ZFS storage page asks for matched drive sizes because RAIDZ treats every disk as the smallest.

Unraid’s file systems page accepts only Btrfs or ZFS for multi-device pools and flags Btrfs RAID 5/6 as still experimental. A ZFS disk inside the parity array is allowed, but Unraid warns it lacks the redundancy of a dedicated ZFS pool: a scrub can find corruption there with no second copy to repair from.

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 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. QNAP is different: QTS uses ext4 and QuTS hero already runs ZFS.

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.

FAQ

is btrfs raid1 stable enough for a nas

Yes. The Btrfs status table, current to Linux 7.2, marks raid1, raid1c3, raid1c4 and raid10 OK for stability, unlike RAID5/6. Two cautions apply: raid1 keeps exactly two copies however many disks you add, and creating a multi-disk filesystem without -d raid1 leaves file data in the single profile with no second copy.

does zfs need ecc ram more than btrfs

No more than Btrfs does. OpenZFS’s hardware guide says no technique in ZFS or any other filesystem can protect against bit flips, and that ECC memory is highly recommended for that reason. The risk is the same for both: data corrupted in RAM before it is checksummed is written to disk with a valid checksum.

can you convert btrfs to zfs without wiping the disks

No. Neither filesystem converts in place to the other, so moving from Btrfs to ZFS means building the pool on separate disks, copying the data across, and only then reusing the old drives. With RAIDZ expansion since OpenZFS 2.3, you can start RAIDZ narrower and attach freed disks later, though early data keeps the narrower layout.

how often should you scrub a zfs or btrfs pool

Monthly is a sensible baseline for either, with weekly for heavily used pools. That is the cadence Unraid’s file system docs give for Btrfs; for ZFS the same docs name scrubbing as the integrity check, since ZFS does not use fsck. Btrfs rates scrub OK in its status table, and scrub on RAID5/6 only mostly OK.