This is the page I wish existed when I was evaluating ZFS in 2016. Every comparison I found was either a ZFS fanboy hit piece or a dismissive "it's fine for NAS" from someone who never ran it in production. This page is honest. ZFS wins most comparisons, but not all — and I'll tell you exactly where the legacy tools are simpler or more appropriate.

# Legacy: mdadm + LUKS + LVM + ext4 (15+ commands)
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
mdadm --detail --scan >> /etc/mdadm.conf
cryptsetup luksFormat /dev/md0
cryptsetup luksOpen /dev/md0 crypt0
pvcreate /dev/mapper/crypt0
vgcreate vg0 /dev/mapper/crypt0
lvcreate -L 100G -n data vg0
mkfs.ext4 /dev/vg0/data
mkdir -p /data
mount /dev/vg0/data /data
# ...plus fstab, crypttab, mdadm.conf, dracut/initramfs updates

# ZFS: one command
zpool create -o ashift=12 \
  -O compression=lz4 -O atime=off -O encryption=aes-256-gcm \
  -O keyformat=passphrase -O keylocation=prompt \
  tank mirror /dev/sda /dev/sdb

I've set up the legacy stack hundreds of times. Every time, I forget one step — the crypttab entry, the dracut rebuild, the fstab UUID. With ZFS, I run one command and walk away. The mountpoint is a dataset property. The encryption is a dataset property. The RAID is the pool topology. There is nothing else to configure.

I still use ext4 for /boot and the EFI system partition. It's the right tool for small, static partitions that UEFI firmware and bootloaders need to read. For everything else — root, home, data, VMs, containers — ZFS.

If someone tells me they run XFS on bare metal with mdadm RAID10, I respect that. It's a solid stack. But the moment they need snapshots, replication, or compression, they're bolting on new tools. ZFS gives you all of it from day one. And it checksums the data, which XFS still doesn't.

I actually like Btrfs for laptop root filesystems — it's in-tree, snapshots work great with snapper, and RAID1 is solid. But the moment you need parity RAID, encryption, or you're storing data you really cannot lose, ZFS is the only answer. The write hole in Btrfs RAID5/6 has been open for over a decade. That tells you everything about the project's priorities.

ZFS vs mdadm — software RAID

mdadm is the Linux software RAID implementation. It operates at the block layer, below the filesystem. It knows nothing about the data it stores — just blocks. This is both its strength (simplicity, flexibility) and its fatal flaw (no data integrity).

The write hole is mdadm's most dangerous problem. In RAID5/6, a power failure during a write can leave parity inconsistent with data. On next boot, mdadm has no way to know which blocks are correct. The write-intent bitmap mitigates this but doesn't eliminate it. ZFS's copy-on-write design makes a write hole physically impossible — new data is always written to new locations, and the uberblock pointer is updated atomically.

# mdadm: create RAID1 + filesystem (multiple tools, multiple steps)
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
mkfs.ext4 /dev/md0
mount /dev/md0 /data

# ZFS: one command, same result, plus checksums + snapshots + compression
zpool create -o ashift=12 -O compression=lz4 tank mirror /dev/sda /dev/sdb

ZFS vs hardware RAID — the vendor trap

Hardware RAID controllers (Dell PERC, HP Smart Array, LSI MegaRAID, Broadcom) move RAID computation to a dedicated chip. For decades, this was considered the "enterprise" approach. In 2026, hardware RAID is a liability for ZFS — and increasingly for everything else too.

The controller failure scenario is the killer. If your Dell PERC H740 dies, you need another H740 (or compatible) to read the array. If that model is discontinued, you're buying used cards on eBay and praying. With ZFS, you pull the disks, put them in any machine running OpenZFS, and zpool import tank. Done.

The BBU dependency is the second killer. Hardware RAID controllers rely on a battery backup unit to protect the write cache during power failure. Batteries degrade. When the BBU reports degraded, the controller disables write-back caching and performance falls off a cliff. Or worse: the battery is dead but the controller doesn't report it, and you have an unprotected write cache. ZFS doesn't need a battery because copy-on-write never overwrites live data.

ZFS vs LVM — the volume manager

LVM2 is the standard Linux volume manager. It provides logical volumes, thin provisioning, snapshots (of a sort), and the ability to span or stripe across multiple disks. ZFS replaces LVM entirely — datasets are the equivalent of logical volumes, but with far more capabilities.

Where LVM wins: online shrink (ZFS pools cannot shrink), deep integration with every Linux distro's installer, and simpler mental model for admins who only need basic volumes. LVM also integrates with LUKS and mdadm in well-documented ways.

Where LVM loses: LVM classic snapshots are notoriously slow — every write to the origin volume triggers a copy-on-write to the snapshot exception store, degrading performance by 30–80%. LVM thin snapshots are better but add significant complexity (thin pools, metadata volumes, autoextend thresholds). ZFS snapshots are free — zero performance impact, zero configuration.

ZFS vs Ceph — local vs distributed

Ceph is a distributed storage system that provides block (RBD), object (RADOS), and file (CephFS) storage across a cluster of machines. Comparing ZFS to Ceph is comparing a local storage platform to a distributed one — they solve different problems, but the comparison comes up constantly because both are used for "serious" storage.

Ceph wins when you need data accessible across multiple machines simultaneously, when you need to survive entire node failures without service interruption, or when you're building a cloud platform that serves block storage to hundreds of VMs.

ZFS wins when you need local storage performance, operational simplicity, or you're running on a single machine. Fun fact: many Ceph clusters use ZFS as the OSD backing store (via BlueStore on raw ZFS zvols) to get checksumming and compression underneath Ceph's distributed layer.

ZFS vs DRBD — synchronous replication

DRBD (Distributed Replicated Block Device) provides synchronous block-level replication between two nodes. It's often used for database HA: primary writes to local disk and DRBD simultaneously replicates every write to the secondary. If the primary dies, the secondary has an identical copy.

DRBD wins when you absolutely need zero RPO — database HA clusters where losing even one transaction is unacceptable. Synchronous replication guarantees the secondary has every committed write.

ZFS wins when you can tolerate a few minutes of potential data loss (which is most workloads). zfs send/recv is dramatically simpler to operate, doesn't impact write latency, and includes checksums on both sides. For most server replication, syncoid --no-sync-snap tank tank/backup@remote in a cron job is all you need.

The master comparison table

Every major feature across every storage technology in one table. This is the reference.

* Btrfs self-healing requires RAID1/10 profiles. RAID5/6 is not reliable.
** Btrfs RAID 0/1/10 is stable. RAID 5/6 has a known write hole and is not production-safe.

RAID implementation comparison

Migration paths to ZFS

You can't convert an existing filesystem to ZFS in-place. Migration always involves creating a new ZFS pool and copying data. Here are the practical paths for each legacy system.

From ext4 / XFS (single disk or LVM)

# 1. Create ZFS pool on new disk(s)
zpool create -o ashift=12 -O compression=lz4 -O atime=off tank mirror /dev/sdc /dev/sdd

# 2. Copy data preserving permissions, xattrs, ACLs
rsync -avxHAX --progress /old-mount/ /tank/data/

# 3. Verify
diff -r /old-mount/ /tank/data/

# 4. Update fstab/mountpoints, reboot, decommission old disks

From mdadm RAID

# 1. Back up mdadm config
mdadm --detail --scan > /root/mdadm-backup.conf

# 2. Create ZFS pool on separate disks
zpool create -o ashift=12 -O compression=lz4 tank mirror /dev/sde /dev/sdf

# 3. Copy data
rsync -avxHAX /old-raid-mount/ /tank/data/

# 4. Stop mdadm array after verification
mdadm --stop /dev/md0
mdadm --zero-superblock /dev/sda1 /dev/sdb1

# 5. Optionally add old disks to the ZFS pool
zpool add tank mirror /dev/sda /dev/sdb

From hardware RAID

# 1. Copy data to external storage or new ZFS pool
rsync -avxHAX /old-mount/ /tank/data/

# 2. Flash RAID controller to IT/HBA mode (or replace with HBA)
#    Dell PERC: use Dell firmware utility
#    LSI: use sas2flash or sas3flash
#    This exposes raw disks to the OS

# 3. Create ZFS pool on the now-exposed raw disks
zpool create -o ashift=12 -O compression=lz4 \
  tank mirror /dev/sda /dev/sdb mirror /dev/sdc /dev/sdd

# 4. Restore data
rsync -avxHAX /backup/ /tank/data/

From Btrfs

# 1. Create ZFS pool on new disks
zpool create -o ashift=12 -O compression=zstd tank mirror /dev/sdc /dev/sdd

# 2. Use btrfs send to extract snapshots, pipe through tar
# (btrfs send/recv is Btrfs-only — can't receive into ZFS)
btrfs subvolume snapshot -r /btrfs-mount /btrfs-mount/migration-snap
rsync -avxHAX /btrfs-mount/migration-snap/ /tank/data/

# 3. Recreate subvolume structure as ZFS datasets
zfs create tank/data/home
zfs create tank/data/var
rsync -avxHAX /btrfs-mount/home/ /tank/data/home/
rsync -avxHAX /btrfs-mount/var/ /tank/data/var/

When NOT to use ZFS

ZFS is the right answer for most storage needs. But not all. Here are the cases where legacy tools are simpler or more appropriate. Being honest about this makes the rest of the page more credible.

Operational complexity comparison

One of ZFS's biggest advantages isn't a feature — it's the operational simplicity of having one tool instead of five. Here's what common storage tasks look like in each stack.

Scalability limits

In practice, you'll hit hardware limits (RAM, CPU, disk count) long before you hit ZFS's theoretical limits. The practical ceiling for a single ZFS pool is around 2 PB on current hardware — beyond that, you're looking at distributed solutions like Ceph or Lustre.

Performance characteristics

Raw sequential throughput is not where ZFS shines compared to ext4 or XFS. ZFS's performance advantages come from compression (less data written to disk), ARC caching (hot data served from RAM), and the special vdev (metadata on SSD). Here's an honest assessment.

The verdict