Common ZFS Myths — debunked with evidence.

ZFS has been in production since 2005. In two decades it has accumulated a mythology — half-truths from the Solaris era, outdated limitations from early OpenZFS, and outright misinformation recycled on forums. This page examines the fifteen most common myths, rates each one, and provides the commands and evidence you need to make informed decisions instead of repeating things you read on Reddit in 2014.

Myth 1: "ZFS requires ECC RAM"

What actually happens without ECC: A memory bit flip could corrupt data in any filesystem's write path. ZFS's checksumming will detect this corruption on the next read — which is more than ext4, XFS, or Btrfs (without checksumming enabled) can say. The checksum won't tell you the data was corrupted in RAM before it was written — it will tell you the data on disk doesn't match what it should be. With redundancy (mirror/RAIDZ), ZFS can even repair it from the good copy.

The real advice: ECC RAM is recommended for any server storing important data, regardless of filesystem. It is not a ZFS-specific requirement. Millions of ZFS installations run on non-ECC hardware (every TrueNAS Mini, every home NAS, every Proxmox homelab). They work fine.

# Check if your system has ECC RAM (Linux)
dmidecode -t memory | grep "Error Correction Type"

# ZFS will happily create a pool either way:
zpool create tank mirror /dev/sda /dev/sdb
# No ECC check. No warning. It just works.

Myth 2: "ZFS eats all your RAM"

The fear comes from watching free -h or htop and seeing high memory usage. But ARC memory is reclaimable. The kernel can reclaim it under pressure just like it reclaims page cache. On Linux, ZFS defaults to using at most 50% of total RAM for ARC. On FreeBSD, the default is higher (up to 90% on dedicated storage boxes), and it tunes aggressively under pressure.

If you want to set an explicit limit — common on mixed-use systems running VMs or databases — set zfs_arc_max. This is a ceiling, not a reservation. ARC will grow up to this limit and no further.

# Check current ARC usage and hit ratio
arc_summary

# Or the quick version:
cat /proc/spl/kstat/zfs/arcstats | grep -E "^(size|c_max|hits|misses)"

# Set ARC max to 8GB (takes effect immediately, persists via modprobe.d)
echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max

# Make it persistent:
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf

A healthy ARC hit ratio is 90%+ for most workloads. If your ARC hit ratio is below 80%, you either have a random-access workload that doesn't benefit from caching, or you've set zfs_arc_max too low. Check with arc_summary and look at the "ARC efficiency" section.

Myth 3: "You can't expand a RAID-Z vdev"

The feature was the most requested in ZFS history. Matthew Ahrens (co-creator of ZFS) designed and implemented it. It works by reading every block in the vdev and rewriting it with the new stripe width. This is a slow operation — comparable to a full resilver — but it runs in the background while the pool remains online and fully operational.

# Existing RAIDZ1 with 3 disks:
zpool status tank
#   raidz1-0  ONLINE
#     sda     ONLINE
#     sdb     ONLINE
#     sdc     ONLINE

# Add a fourth disk to the existing RAIDZ1 vdev:
zpool attach tank raidz1-0 /dev/sdd

# Monitor expansion progress:
zpool status tank
# scan: expansion in progress, 45.2% done, 3h12m to go

Constraints: You can add one disk at a time. You cannot change the parity level (e.g., RAIDZ1 to RAIDZ2) during expansion. The expansion must finish before you can add another disk. Performance is reduced during the reflow. These are reasonable tradeoffs for a feature the community waited over a decade to get.

Minimum version: OpenZFS 2.3.0 or later. Check with zfs --version. Ubuntu 24.04 ships 2.2.x — you'll need to upgrade or use a backport PPA. FreeBSD 14.1+ includes it.

Myth 4: "You need 1GB of RAM per TB of storage"

What actually determines ZFS memory requirements:

Practical guidelines: 2GB minimum for a basic ZFS system. 4–8GB for a general NAS. 16–32GB for a busy VM host with multiple pools. 64GB+ for large-scale storage with heavy metadata. These numbers depend on workload, not capacity. A 100TB cold archive serving 3 users needs less RAM than a 2TB database serving 1000 concurrent connections.

# See exactly what ARC is doing with your RAM:
arc_summary | head -40

# Check metadata vs data in ARC:
arc_summary | grep -A5 "ARC size"

# Real example — 20TB pool running fine on 8GB total RAM:
# ARC: 3.5G (target: 4G), hit ratio: 94.2%
# No dedup. LZ4 compression. Happy system.

Myth 5: "ZFS is slow"

Why ZFS is often faster in practice:

LZ4 compression is enabled by default and runs at 5+ GB/s on modern CPUs. A 4:1 compressible workload means ZFS reads/writes 75% less data to/from disk. The CPU overhead is negligible; the I/O savings are enormous. Your "slow" ZFS pool is reading 4x less from disk than the ext4 partition next to it.

ARC caches frequently-accessed data in RAM. A warm ARC serves reads at memory speed — orders of magnitude faster than any SSD, let alone spinning rust. Ext4 has the page cache, but ARC is more sophisticated (it uses an adaptive replacement algorithm that handles both frequency and recency).

Checksumming overhead is the real cost: roughly 2–5% for SHA-256, negligible for fletcher4 (the default). On modern CPUs with SHA-NI instructions, even SHA-256 is barely measurable. This is the price of knowing your data is intact — a price that every other filesystem pays in silent corruption instead.

# Benchmark with compression — real-world scenario:
fio --name=test --ioengine=libaio --rw=randread --bs=4k --numjobs=4 \
  --size=1G --runtime=60 --time_based --group_reporting \
  --directory=/tank/benchmark

# Check compression ratio — this is your "free" speed boost:
zfs get compressratio tank
# NAME  PROPERTY       VALUE  SOURCE
# tank  compressratio  2.31x  -

# Check ARC hit ratio — this is your "free" RAM cache:
cat /proc/spl/kstat/zfs/arcstats | grep -E "hits|misses"

Myth 6: "ZFS is too complex for production"

The traditional Linux storage stack for redundant, managed storage:

You need mdadm for software RAID. lvm2 for volume management and snapshots. ext4 or xfs for the filesystem. smartmontools for disk health. A separate backup tool for send/receive. A separate integrity checker if you want checksumming (there isn't a good one). Three separate man pages, three separate config syntaxes, three separate failure modes. When something breaks, you debug the interaction between three layers that were never designed to work together.

The ZFS stack: zpool and zfs. Two commands. RAID, volume management, filesystem, snapshots, send/receive, checksumming, compression, and encryption are all integrated into a single coherent system. When something breaks, zpool status tells you exactly what's wrong and what to do about it.

# Traditional stack — create redundant storage with snapshots:
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
pvcreate /dev/md0
vgcreate vg0 /dev/md0
lvcreate -L 100G -n data vg0
mkfs.ext4 /dev/vg0/data
mount /dev/vg0/data /data
# Snapshots? That's another LVM command. Checksums? Not available.

# ZFS — same thing, all integrated:
zpool create tank mirror /dev/sda /dev/sdb
zfs create tank/data
# Done. Checksumming on. Compression on. Snapshots: zfs snapshot tank/data@backup

Myth 7: "You can't use ZFS on Linux, it's not in the kernel"

How ZFS on Linux works: The OpenZFS project ships a kernel module that builds against the running kernel via DKMS (Dynamic Kernel Module Support). When you install zfs-dkms or the prebuilt zfs package, DKMS compiles the module for your exact kernel version. On kernel upgrades, DKMS rebuilds automatically. This is the same mechanism used by NVIDIA drivers, VirtualBox, and dozens of other out-of-tree modules.

Ubuntu has shipped ZFS as a supported root filesystem since 19.10 (2019). Canonical maintains the packages, tests them against every kernel update, and provides commercial support. Proxmox VE, the most popular open-source virtualization platform, ships ZFS as a first-class option in its installer. Neither company would stake their reputation on something that "doesn't work."

The legal situation: The CDDL and GPL are both open-source licenses. Their incompatibility is a matter of legal interpretation, not technical limitation. Canonical's legal team has reviewed this and ships ZFS in the Ubuntu kernel. The FSF disagrees with this interpretation. No lawsuit has ever been filed. The code works. The legal debate is for lawyers, not operators.

# Install ZFS on major distros:

# Ubuntu (prebuilt, supported by Canonical):
apt install zfsutils-linux

# Fedora/RHEL/Rocky (via OpenZFS repo):
dnf install https://zfsonlinux.org/fedora/zfs-release-2-5$(rpm --eval "%{dist}").noarch.rpm
dnf install zfs

# Arch Linux:
pacman -S zfs-dkms

# Debian 13+ (Trixie):
apt install zfsutils-linux

# Check it's loaded:
lsmod | grep zfs
zfs --version

Myth 8: "Dedup is unusable"

Fast Dedup (OpenZFS 2.2+): The new implementation stores the DDT on a special vdev (fast SSD) instead of requiring it all in RAM. The in-memory footprint dropped by 10–100x. A workload that previously needed 64GB of RAM for dedup can now run with 4–8GB of RAM plus a fast NVMe special vdev. This makes dedup practical for the first time on real-world hardware.

When dedup makes sense now: VM storage with many similar guests (dedup ratios of 3–10x are common). Backup repositories with many similar backups. CI/CD environments with thousands of similar container images. Any workload where the same blocks are written repeatedly.

When dedup still doesn't make sense: Media storage (video, photos — already compressed, nothing to dedup). General file servers with diverse data. Any pool without a fast special vdev for the DDT. Compression (LZ4) is almost always a better first choice — it's free, requires no RAM overhead, and provides 2–4x space savings on compressible data.

# Check if dedup would help BEFORE enabling it:
zdb -S tank
# Simulates dedup across the entire pool without enabling it.
# Look at "dedup = X.XX", where > 2.0 means dedup would save space.

# Enable fast dedup (OpenZFS 2.2+) with DDT on special vdev:
zpool add tank special mirror /dev/nvme0n1 /dev/nvme1n1
zfs set dedup=on tank/vms

# Monitor DDT size:
zpool status -D tank

# If you're on < 2.2, the old advice stands: don't enable dedup.
# Use compression instead:
zfs set compression=lz4 tank

Myth 9: "You can't shrink a pool"

What works: zpool remove can remove top-level vdevs that are mirrors or single disks. When you remove a vdev, ZFS evacuates all data from it to the remaining vdevs in the pool. This is a slow, background operation, but it works online with no downtime.

What doesn't work: You cannot remove a RAIDZ vdev from a pool. You cannot remove the last vdev. You cannot remove a vdev if the remaining vdevs don't have enough free space to hold the evacuated data. These are fundamental limitations of the pool geometry.

# Pool with three mirror vdevs:
zpool status tank
#   mirror-0  ONLINE  (sda, sdb)
#   mirror-1  ONLINE  (sdc, sdd)
#   mirror-2  ONLINE  (sde, sdf)

# Remove the third mirror pair:
zpool remove tank mirror-2

# Monitor evacuation progress:
zpool status tank
# removal in progress, 34% done

# This does NOT work with RAIDZ vdevs:
zpool remove tank raidz1-0
# cannot remove raidz1-0: only mirror and single-device vdevs can be removed

The practical workaround for RAIDZ: Create a new, smaller pool. Use zfs send | zfs recv to migrate datasets. Destroy the old pool. This is the "ZFS way" of reshaping storage — it's not as elegant as online shrinking, but it preserves all data, snapshots, and properties.

Myth 10: "ZFS licensing prevents enterprise adoption"

Companies running ZFS in production at scale:

The CDDL is an open-source license approved by the OSI. It permits commercial use, modification, and distribution. The only restriction is that modifications to CDDL-licensed files must remain under CDDL. This is less restrictive than GPL in some ways. The "licensing problem" is specifically about combining CDDL and GPL code in the same binary (the Linux kernel). It does not affect running ZFS as a loadable kernel module, which is how every Linux deployment works.

Myth 11: "Btrfs is the Linux answer to ZFS"

Where Btrfs matches or exceeds ZFS: Kernel integration (it's in-tree). Subvolume flexibility (more granular than ZFS datasets in some workflows). Send/receive for snapshots. Transparent compression. Reflinks for instant file copies. SUSE and Facebook/Meta use it extensively in production. Fedora uses it as the default filesystem.

Where Btrfs falls short:

Honest assessment: Btrfs is a good filesystem for single-disk or RAID1 desktop use. Fedora and openSUSE default to it, and it works well there. For multi-disk servers, large-scale storage, or anything requiring parity RAID, ZFS remains the stronger choice. This isn't tribal loyalty — it's engineering reality. Use the tool that's mature for your use case.

Myth 12: "ZFS doesn't work with SSDs"

TRIM support: ZFS supports both periodic TRIM (zpool trim) and automatic TRIM (autotrim=on). Periodic TRIM runs as a one-time operation; autotrim discards freed blocks continuously. For most SSD pools, autotrim=on is the right choice as it maintains consistent SSD performance without manual intervention.

SSD-optimized settings: ZFS's copy-on-write design is actually better for SSDs than in-place-update filesystems. COW means ZFS never overwrites data — it always writes to new locations. This distributes writes across the SSD evenly, providing natural wear leveling on top of the SSD's internal wear leveling. Write amplification is lower than ext4 for many workloads because COW avoids the journal write + data write pattern.

# Create an all-flash pool with autotrim:
zpool create -o ashift=12 -o autotrim=on \
  -O compression=lz4 -O atime=off \
  tank mirror /dev/nvme0n1 /dev/nvme1n1

# Enable autotrim on an existing pool:
zpool set autotrim=on tank

# Run a one-time TRIM (useful after large deletes):
zpool trim tank

# Check TRIM progress:
zpool status -t tank

# Verify ashift=12 (critical for NVMe):
zpool get ashift tank

All-flash pool design: SSDs eliminate the random I/O penalty that makes RAIDZ problematic for databases on spinning disks. An all-NVMe RAIDZ2 pool can handle mixed workloads that would require mirrors on HDDs. That said, mirrors still provide better peak IOPS. The ARC is less critical on all-flash pools since the underlying storage is already fast, but it still helps for hot data.

Myth 13: "You need identical disks"

Size mismatches: In a mirror, each disk stores a complete copy. A 4TB + 8TB mirror gives you 4TB usable — the extra 4TB on the larger disk is wasted. In RAIDZ, the usable space per disk is capped at the smallest disk's size. This isn't a ZFS limitation — it's basic RAID math. Any RAID system wastes space when disks are mismatched.

The ashift concern: ashift is set per vdev at creation and cannot be changed. If you create a vdev with ashift=12 (4K sectors) and later add a disk that actually needs ashift=13 (8K sectors, some newer NVMe), the misalignment causes write amplification. Always use ashift=12 or higher. Never use ashift=9 on modern hardware.

Speed mismatches: Mixing a 7200 RPM HDD with a 5400 RPM HDD in a mirror means the vdev performs at the speed of the slower disk for writes (both must complete). Reads can favor the faster disk. Mixing SSDs with HDDs in the same vdev is possible but rarely sensible — the SSD waits for the HDD on writes. Use SSDs as special vdevs, SLOG, or L2ARC instead.

# This works but wastes space — 4TB mirror from mixed sizes:
zpool create tank mirror /dev/sda  # 8TB
                        /dev/sdb   # 4TB
# Result: 4TB usable, 4TB wasted on sda

# Check sector sizes before creating a pool:
lsblk -o NAME,PHY-SEC,LOG-SEC
# If all disks show 4096/512 or 4096/4096, ashift=12 is correct.

# Safe practice — always specify ashift explicitly:
zpool create -o ashift=12 tank mirror /dev/sda /dev/sdb

Myth 14: "ZFS can't recover from bit rot without ECC"

How ZFS detects bit rot: Every block written to a ZFS pool has a checksum stored in its parent block's pointer (not on the same disk sector — this is critical). When ZFS reads a block, it verifies the checksum. If the checksum doesn't match, ZFS knows the data is corrupt. With redundancy (mirror or RAIDZ), ZFS reads the good copy from another disk and repairs the corrupt one automatically. No ECC RAM required for any of this.

What ECC RAM prevents: If a bit flips in RAM before ZFS writes data to disk, ZFS checksums the corrupted data and writes it with a valid checksum. The on-disk data is silently wrong, and ZFS can't detect it because the checksum matches the (corrupted) data. ECC RAM prevents this by detecting and correcting single-bit memory errors before they reach the filesystem. This is the same risk for every filesystem — ext4 and XFS are equally vulnerable and don't even have checksums to catch the disk-side corruption.

# Scrub detects and repairs bit rot on redundant pools:
zpool scrub tank

# Check scrub results:
zpool status tank
# scan: scrub repaired 4K in 02:15:32 with 0 errors
#   NAME        STATE     READ WRITE CKSUM
#   tank        ONLINE       0     0     0
#     mirror-0  ONLINE       0     0     0
#       sda     ONLINE       0     0     1  # <- bit rot detected and repaired
#       sdb     ONLINE       0     0     0

# Schedule regular scrubs (monthly is recommended):
systemctl enable zfs-scrub-monthly@tank.timer

# Check what checksum algorithm is in use:
zfs get checksum tank
# Default is on (fletcher4). SHA-256 for paranoid: zfs set checksum=sha256 tank

The bottom line: ZFS catches bit rot. ECC RAM prevents memory corruption. They solve different problems. A ZFS pool on non-ECC RAM is still dramatically safer than ext4 on non-ECC RAM, because ZFS detects on-disk corruption that ext4 silently delivers to your application.

Myth 15: "Hardware RAID is faster than ZFS"

The write hole: Hardware RAID5/6 has the "write hole" problem. If power is lost during a partial stripe write, the parity is inconsistent with the data. On next boot, the array doesn't know which blocks are correct. Some controllers use battery-backed write caches (BBU/BBM) to mitigate this, but the mitigation is a band-aid — it relies on the battery holding charge and the controller firmware being correct. ZFS's copy-on-write design eliminates the write hole entirely. Data is always consistent on disk because ZFS never overwrites live data.

Silent corruption: Hardware RAID operates below the filesystem. It moves blocks without understanding what they contain. If a disk returns the wrong data (firmware bug, cable fault, controller error), hardware RAID delivers that wrong data to the filesystem with no indication of an error. ZFS checksums every block and detects this corruption. Hardware RAID cannot.

Performance reality: A modern Xeon or EPYC can compute SHA-256 checksums at 10+ GB/s using hardware acceleration. The bottleneck is always the disks, not the CPU. ZFS's ARC and compression often make it faster in practice — a 3:1 compression ratio means ZFS writes 3x less data to disk than a hardware RAID controller would for the same workload.

# Never use ZFS on top of hardware RAID. Flash controllers to IT/HBA mode.
# IT mode passes disks directly to the OS — ZFS needs direct access.

# If your controller supports IT mode (LSI/Broadcom):
# Flash to IT firmware using sas2flash or storcli

# Verify disks are visible individually:
lsblk
# You should see /dev/sda, /dev/sdb, etc. — not a single /dev/sda from the RAID card.

# Check if ZFS can use CPU-accelerated checksums:
cat /proc/cpuinfo | grep sha_ni
# If sha_ni is present, SHA-256 checksums run at hardware speed.

Bonus: quick myths

These myths come up frequently but don't need full sections. Quick verdicts:

The pattern

Most ZFS myths share a common structure: something that was true in 2010 on Solaris or early Linux gets repeated for 15 years without anyone checking if it's still true. The filesystem has evolved dramatically — RAIDZ expansion, fast dedup, vdev removal, TRIM, persistent L2ARC, native encryption — but the myths haven't kept up.

The best defense against mythology is evidence. Every claim on this page can be verified with the commands shown. If you hear a new myth, test it. zpool and zfs will give you a straight answer faster than any forum post.