Btrfs vs ZFS: Choosing the Right Next-Generation Filesystem

Btrfs and ZFS are both copy-on-write filesystems with checksums, snapshots and built-in volume management. On paper they solve the same problem: making sure the data you read back is the data you wrote, and letting you roll back when something goes wrong. In practice they come from very different places, and the right choice depends on your hardware, your distro and how much you want to tinker.

I use both: Btrfs on a Synology NAS and on Linux desktops, and ZFS where I want big, simple, redundant pools. This post compares them on the points that actually matter when you're choosing.

What copy-on-write gives you

Traditional filesystems like ext4 overwrite blocks in place. Copy-on-write (CoW) filesystems write changed data to a new location, then update the metadata to point at it. That design gives both Btrfs and ZFS the same core features:

• Checksums on data and metadata. Silent corruption (bit rot, a flaky cable, a dying disk returning bad sectors) is detected on read instead of quietly passed to your application.
• Cheap snapshots. A snapshot is just a frozen set of pointers. Taking one is instant and costs no space until data changes.
• Send/receive replication. Both can stream the difference between two snapshots to another machine, which makes incremental off-site backups efficient.
• Transparent compression. zstd or lz4 often saves space and can even speed up reads on slow disks.

Checksums only *detect* corruption. To *repair* it, the filesystem needs a second good copy, from a mirror or parity. Keep that in mind when we get to RAID.

Btrfs in brief

Btrfs has been in the mainline Linux kernel for years and is the default root filesystem on Fedora and openSUSE. Because it ships with the kernel, there's nothing extra to install or rebuild after kernel updates.

Its standout feature is subvolumes: independent filesystem trees inside one Btrfs volume that you can snapshot, mount and send separately.

sudo btrfs subvolume create /data/projects
sudo btrfs subvolume snapshot -r /data/projects /data/.snapshots/projects-$(date +%F)
sudo btrfs subvolume list /data

A read-only snapshot (-r) is what you need for btrfs send:

sudo btrfs send /data/.snapshots/projects-2026-10-01 | ssh backup-host sudo btrfs receive /backup/

Routine health checks:

sudo btrfs scrub start -B /data     # read everything, verify checksums
sudo btrfs device stats /data       # per-device error counters
sudo btrfs filesystem usage /data   # real space usage (df can mislead)

Tools like Snapper or Timeshift automate snapshots before package updates, which is how Fedora and openSUSE make it easy to roll back a bad upgrade.

The caveat: Btrfs's own RAID1 and RAID10 profiles are mature, but its parity modes (RAID5/6) are still not recommended for important data. The Btrfs documentation itself warns about them. If you want parity RAID with Btrfs, put Btrfs on top of Linux md RAID instead, which is exactly what Synology does.

The Synology angle

Synology DSM uses Btrfs as the filesystem on most of its models, but it doesn't use Btrfs's native RAID. Volumes sit on Linux md RAID (Synology's SHR is md plus LVM underneath), with Btrfs on top. That avoids the Btrfs RAID5/6 issues while keeping the useful parts:

• Snapshot Replication is Btrfs snapshots with a friendly scheduler and retention rules. It's the best protection against ransomware or a careless rm -rf on a shared folder.
• Data scrubbing reads every block and verifies checksums. With data checksums enabled on a shared folder, Synology says DSM can use the RAID redundancy to repair a corrupt block automatically.
• Per-folder checksums and compression are options you set when creating a shared folder.

Two practical tips if you run a Synology: enable data checksums when you create shared folders (it can't be added later to an existing folder), and schedule a data scrub every month or two in Storage Manager.

ZFS in brief

ZFS (OpenZFS on Linux and FreeBSD) combines the volume manager and filesystem in one tool. You build a pool from vdevs (mirrors or RAIDZ groups), then create datasets with their own properties:

sudo zpool create tank mirror /dev/disk/by-id/ata-DISK1 /dev/disk/by-id/ata-DISK2
sudo zfs create -o compression=lz4 -o atime=off tank/projects
sudo zfs snapshot tank/projects@2026-10-01
sudo zfs list -t snapshot
sudo zpool scrub tank
sudo zpool status -v tank

Use /dev/disk/by-id/ paths, not /dev/sdX, so the pool survives disks being renamed.

ZFS's strengths are maturity and predictability. RAIDZ1/2/3 parity RAID is trusted in production, zpool status tells you exactly what's wrong, and zfs send -i replication is rock solid. It also has a very effective RAM cache (the ARC).

The trade-offs:

• Licensing. OpenZFS is CDDL-licensed, so it can't be merged into the Linux kernel. Ubuntu ships it ready to use. Elsewhere it's usually a DKMS module, which needs rebuilding on kernel updates and can lag behind brand-new kernels.
• Memory. The ARC will use spare RAM by design (it gives it back under pressure). ZFS runs fine on modest machines, but it's happiest with plenty of memory, and deduplication in particular needs a lot. Leave dedup off unless you've measured that you need it.
• Pool layout is a long-term decision. You can add vdevs, and OpenZFS 2.3 added RAIDZ expansion (adding a single disk to an existing RAIDZ vdev), but you still can't freely reshape or shrink a pool the way you can with Btrfs or LVM.

Side-by-side

• Kernel integration: Btrfs is in mainline. ZFS is an out-of-tree module (built in on Ubuntu).
• Mirrors: both are solid.
• Parity RAID: ZFS RAIDZ is production-ready. For Btrfs, use md RAID underneath, not native RAID5/6.
• Flexibility: Btrfs can add, remove and rebalance disks of mixed sizes. ZFS pools are more rigid.
• Snapshots and replication: both excellent. ZFS's tooling is more consistent; Btrfs integrates nicely with Snapper and Timeshift.
• Root filesystem on a Linux desktop: Btrfs is the easy option on Fedora and openSUSE.
• Tooling and error reporting: ZFS is clearer, especially zpool status.

Which should you pick?

• A Linux desktop or laptop: Btrfs. Snapshots before updates are a real safety net, and there's no extra module to manage. Combine it with full-disk encryption; see my LUKS and TPM2 guide.
• A Synology or similar NAS: Btrfs, as the vendor intends, with checksums, scheduled scrubs and snapshot replication turned on.
• A DIY storage server with several disks: ZFS with mirrors or RAIDZ2 is hard to beat, especially on Ubuntu, TrueNAS or Proxmox.
• Mixed disk sizes you'll grow over time: Btrfs RAID1, or LVM if you don't need checksums. My LVM deep dive covers the flexible-volumes side.

Whichever you choose, remember that snapshots are not backups. They live on the same disks. Send them to another machine, and test a restore now and then.

Need help planning storage, backups or a server for your business? I set these up as part of my web and infrastructure work. See my portfolio.