Common Myths — things people believe that aren't true.
"RAIDZ is always better than mirrors"
False. RAIDZ is optimized for sequential workloads. Mirrors provide significantly better random IOPS performance. Use mirrors for VMs and databases. Use RAIDZ2/3 for archives and bulk storage.
"Deduplication is a great way to save space"
Usually false. Dedup requires 1-2GB of RAM per TB and can cripple performance. Use LZ4 compression instead — real savings with near-zero cost.
"Snapshots are a backup strategy"
Dangerously false. Snapshots protect against logical corruption. They do NOT protect
against hardware failure. If the pool dies, all snapshots die with it. Use zfs send/recv for real backups.
"ZFS RAID is just like hardware RAID"
False. ZFS is a copy-on-write filesystem with integrated checksumming. Hardware RAID is block-level abstraction that can't detect silent corruption. Never use ZFS on top of hardware RAID. Use IT-mode HBAs.
"A SLOG is a write cache"
False. SLOG only improves synchronous write performance (databases, NFS, VMs). If your workload doesn't use sync writes, you don't need a SLOG.
"L2ARC increases write performance"
False. L2ARC is a read cache. It keeps frequently-accessed data on a fast SSD to avoid hitting slow disks. For better writes, focus on ARC tuning, pool layout, and SLOG.
"You can expand RAIDZ by adding disks"
False. You cannot add disks to an existing RAIDZ vdev. You must add an entirely new vdev. If you need easy expansion, mirrors are the better choice.
"ZFS automatically uses all available RAM"
Partially true, but misleading. ARC is designed to use available RAM, but it should be tuned.
On Linux, set zfs_arc_max to prevent the kernel from fighting ZFS for memory.
"Consumer SSDs are fine for ZFS"
False for SLOG and special vdevs. Many consumer SSDs lack power loss protection and have poor write endurance under ZFS workloads. Enterprise SSDs with PLP are mandatory for SLOG. Consumer SSDs are acceptable for L2ARC (read-only workload) but not for write-path devices.