Hardware Selection — ZFS is only as good as the metal it runs on.

ZFS is highly dependent on disk latency and throughput. The wrong hardware doesn't just slow things down — it can cause data loss. Consumer SSDs, hardware RAID controllers, and SMR drives are the three most common hardware mistakes. This page covers every hardware decision you need to make, from RAM to drives to power protection, with concrete part numbers and real-world trade-offs.

HBA vs RAID controller — the golden rule

A Host Bus Adapter (HBA) in IT (Initiator Target) mode passes raw disks straight to the OS. No RAID logic, no write-back cache, no interference. ZFS sees every disk individually, reads S.M.A.R.T. data directly, detects every bad sector, and handles all redundancy itself. This is the only correct way to attach disks to a ZFS system.

Why hardware RAID is harmful to ZFS

Recommended HBA models

Crossflashing a RAID controller to IT mode

Many servers ship with LSI-based RAID controllers (Dell PERC H310/H710, IBM M1015, etc.) that are actually LSI 2008 or 2108 chips with RAID firmware. You can replace the firmware with the IT-mode (HBA) firmware to expose raw disks. The process varies by card but follows this pattern:

# General crossflash process (varies by card — research your specific model):
# 1. Boot into EFI shell or DOS
# 2. Erase existing firmware:
sas2flsh -o -e 6
# 3. Flash IT-mode firmware + BIOS:
sas2flsh -o -f 2118it.bin -b mptsas2.rom
# 4. Set SAS address (required — use the address from the card's sticker):
sas2flsh -o -sasadd 500605bxxxxxxxxx

# After reboot, verify IT mode:
lspci -v | grep -i "LSI\|Broadcom"
# Should show: "Serial Attached SCSI controller" (not "RAID bus controller")

ECC RAM — the real story

ECC RAM is strongly recommended but not required. This is the most debated topic in the ZFS community, and the nuance matters. ZFS checksums every block on disk and verifies those checksums on every read. If corruption is detected, ZFS corrects it from a redundant copy. This entire chain assumes the data in RAM is correct — because that's where the checksum is computed.

Without ECC, a single bit flip in RAM can corrupt data silently. ZFS computes a checksum over the corrupted data, writes the corrupted block and its now-valid-looking checksum to disk, and the corruption becomes permanent. This is not theoretical — Google published a study showing DRAM error rates of 25,000–70,000 FIT per Mbit (roughly one correctable error per GB per year). In a server with 64GB of RAM running 24/7, that's dozens of bit flips per year.

The counterpoint: every filesystem has this problem, not just ZFS. ext4 and XFS suffer the same RAM corruption risk — they just can't detect it at all. ZFS without ECC is still safer than any other filesystem without ECC, because at least ZFS can detect most corruption (the kind that happens on disk, during transfer, or in firmware). ZFS without ECC is vulnerable only to corruption that happens to be in RAM at the moment of checksum computation.

When ECC matters most

SAS vs SATA vs NVMe for ZFS

Three interfaces, three different trade-offs. ZFS works equally well with all three — the choice is about performance requirements, budget, and physical infrastructure.

SATA is the budget choice. Every HBA supports it, every case has bays for it, and the drives are cheap. The 6 Gb/s bandwidth is sufficient for HDDs (which max out at ~250 MB/s) but becomes a bottleneck for SSDs. Fine for spinning-rust pools, limiting for all-flash.

SAS is the enterprise choice. Dual-port for multipath failover, longer cable runs for external disk shelves (JBODs), higher queue depth for workloads with many concurrent I/O operations. SAS HBAs accept both SAS and SATA drives, so SAS backplanes give you maximum flexibility. SAS HDDs are 10K or 15K RPM — faster seeks but lower capacity and higher cost than SATA equivalents.

NVMe is the performance choice. Direct PCIe connection eliminates the SAS/SATA protocol overhead entirely. Queue depth is orders of magnitude higher. For all-flash ZFS pools, SLOG devices, and special vdevs, NVMe is the right answer. The downside: each NVMe drive typically consumes a PCIe slot or M.2 connector, limiting drive count without an NVMe JBOD or a tri-mode HBA like the Broadcom 9400/9500 series.

Drive selection — enterprise vs consumer, CMR vs SMR

CMR vs SMR — the non-negotiable rule

How to identify SMR drives

Manufacturers have been caught shipping SMR drives under model names that previously used CMR. The WD Red (non-Plus) debacle in 2020 is the most famous example. Never trust marketing. Always verify.

# Check the drive's data sheet — look for recording technology
# Manufacturer spec sheets will list "CMR" or "PMR" (good) vs "SMR" (bad)

# Known SMR model families (as of 2025 — always verify current models):
# WD Red (WD40EFAX, WD60EFAX) — NOT the Red Plus or Red Pro
# Seagate Barracuda (many 2TB-8TB models, especially ST2000DM008)
# Seagate Archive (all models — designed for SMR)
# Toshiba P300 (some capacity points)

# Known CMR model families:
# WD Red Plus (WD40EFPX, WD80EFPX) — the "Plus" means CMR
# WD Red Pro (all models)
# WD Ultrastar / HGST (all models)
# Seagate Exos (all models)
# Seagate IronWolf (all models — NAS-rated, CMR)
# Toshiba N300 (NAS-rated, CMR)
# Toshiba MG series (enterprise, CMR)

Enterprise vs consumer drives

Error recovery time (TLER/ERC/CCTL) is the most overlooked spec. When a consumer drive encounters a read error, it retries aggressively for up to 60 seconds trying to recover the sector. During this time, the drive is unresponsive. ZFS (or the HBA) may declare the drive dead and kick it from the pool. Enterprise and NAS drives limit this to 7 seconds, then return an error and let ZFS handle it. This is exactly what you want — ZFS has a redundant copy and can fix the error instantly, but only if the drive reports the failure promptly.

Used enterprise drives — the economics

Decommissioned datacenter drives (WD Ultrastar/HGST, Seagate Exos) are often available at 30–50% of new retail price. A used 14TB Ultrastar HC530 might cost $80–120 versus $250+ new. These drives were designed for 24/7 operation and have years of useful life remaining. The key is to verify their health before trusting them with data.

# Check S.M.A.R.T. data on used drives before building a pool
smartctl -a /dev/sdX

# Key fields to check:
# Reallocated_Sector_Ct — should be 0 or very low
# Current_Pending_Sector — should be 0
# Offline_Uncorrectable — should be 0
# Power_On_Hours — tells you age (8760 hours = 1 year)
# Spin_Retry_Count — should be 0

# Run a full surface scan (takes hours on large drives)
badblocks -b 4096 -wsv /dev/sdX
# WARNING: -w is destructive — writes test patterns. Only on empty drives.

HDD form factors and capacity planning

3.5-inch drives dominate ZFS pools. They offer the highest capacity (up to 30TB+ per drive as of 2026), the best cost per terabyte, and are designed for continuous operation in multi-bay enclosures. All NAS, nearline, and enterprise drives are 3.5-inch.

2.5-inch HDDs are largely irrelevant for ZFS. They max out at 2–5TB, are often SMR, and are being replaced by SSDs in every use case. Avoid them.

Capacity planning tip: Buy the largest drives you can afford. Fewer, larger drives mean fewer points of failure, less power consumption, fewer HBA ports, and simpler cabling. A mirror of 2x 18TB drives gives you 18TB usable with only 2 failure domains. Six 6TB drives in RAIDZ2 give you 24TB usable but with 6 failure domains and 6x the probability of a drive failure.

SSD endurance — DWPD, TBW, and flash types

SSDs wear out as NAND cells degrade from repeated write/erase cycles. Endurance is rated in DWPD (Drive Writes Per Day over warranty period) or TBW (Total Bytes Written over lifetime). ZFS's copy-on-write design means every write is a new write — there are no in-place updates. This increases write amplification compared to filesystems that update blocks in place. Compression and recordsize tuning mitigate this, but SSD endurance matters more on ZFS than on ext4.

DWPD vs TBW — what the numbers mean

DWPD tells you how many times you can overwrite the entire drive per day for the warranty period (typically 5 years). A 1.6TB drive rated at 3 DWPD can sustain 1.6TB x 3 = 4.8TB of writes per day for 5 years. That's 8,760 TBW total.

TBW is the simpler metric: total terabytes written over the drive's lifetime. A consumer 1TB NVMe rated at 600 TBW can sustain 328 GB/day for 5 years. Sounds like a lot, but a busy ZFS pool with sync writes, scrubs, and resilvers can burn through that faster than you'd expect.

# Check current SSD wear level
smartctl -a /dev/nvme0n1 | grep -i "percentage used\|data units written"

# Percentage Used: 3%     — drive is at 3% of rated lifetime
# Data Units Written: 12,345,678  — multiply by 512KB for total bytes written

# Convert Data Units Written to TB:
# (data_units * 512000) / 1000000000000
# Example: 12345678 * 512000 / 1e12 = 6.32 TB written

SLOG devices — the write intent log accelerator

The ZFS Intent Log (ZIL) records synchronous write transactions so they survive power loss. By default it lives on the data disks. A SLOG (Separate LOG device) moves the ZIL to a dedicated, fast, power-safe device. A SLOG only benefits workloads that issue synchronous writes: databases calling fsync(), NFS with sync=always, iSCSI targets, and VM storage over NFS/iSCSI.

A SLOG is not a write cache. Asynchronous writes (the default) bypass the ZIL entirely and go straight to the transaction group. Adding a SLOG to an async workload does nothing.

SLOG sizing

A SLOG only needs to hold 5–10 seconds of synchronous writes. That's the interval between ZFS transaction group (TXG) commits (default: 5 seconds, tunable via zfs_txg_timeout). After each TXG commit, the SLOG data is no longer needed. For most workloads, a 16–32GB SLOG is plenty. Even under heavy NFS sync load, you'd need sustained 1+ GB/s of sync writes to need more than 16GB. A 400GB Optane P4801X as SLOG is massive overkill in capacity — but the latency characteristics make it ideal.

Why consumer NVMe fails as SLOG

The entire purpose of the ZIL is to survive power loss. Consumer NVMe drives have volatile write-back caches — the drive reports a write as complete when it hits the DRAM cache, before it reaches NAND. On power loss, that cached data is gone. ZFS thinks the sync write was safely logged on the SLOG. It wasn't. The application (database, NFS client) thinks the write was committed. It wasn't. Data loss follows.

Power Loss Protection (PLP) means the drive has capacitors that provide enough energy to flush the volatile write cache to NAND during power loss. Enterprise NVMe and Intel Optane have this. Consumer NVMe does not.

SLOG device comparison

L2ARC devices — extending read cache to SSD

L2ARC is a read cache that extends the in-memory ARC onto a fast SSD. It helps when your working set exceeds RAM and the workload is read-heavy: file servers, media libraries, build caches. Any decent SSD works for L2ARC — it doesn't need PLP (it's a cache; loss is harmless) and write endurance requirements are moderate (L2ARC writes are sequential and compressible).

L2ARC sizing guidelines

Good L2ARC devices: Any TLC NVMe SSD with a DRAM cache. Samsung 870 EVO (SATA), Samsung 980 Pro (NVMe), WD Black SN770, Crucial P3 Plus. Avoid QLC — sustained random read performance drops sharply as the drive fills. Enterprise SSDs are nice but overkill for L2ARC.

Special vdev devices — metadata on fast storage

The special vdev stores pool metadata (directory entries, block pointers, file attributes) and optionally small file blocks below the special_small_blocks threshold. On a spinning-rust pool, this means ls, find, du, container layer lookups, and database index reads hit the SSD instead of waiting for platter seeks. The improvement is 10–50x for metadata-heavy operations.

Ideal devices: Intel Optane (best — lowest latency for random reads), enterprise NVMe with PLP (Samsung PM9A3, Micron 7450), or high-endurance consumer NVMe. The special vdev handles both reads and writes, so PLP is more important here than for L2ARC (though ZFS can rebuild the special vdev from data vdevs in theory, you don't want to test this).

# Add a mirrored special vdev — metadata + files under 64K go to SSDs
zpool add tank special mirror /dev/nvme0n1 /dev/nvme1n1
zfs set special_small_blocks=65536 tank

# For databases with 8K pages:
zfs set special_small_blocks=16384 tank/postgres

# Verify special vdev allocation:
zpool list -v tank
# Look for the "special" vdev and its allocated/free space

Boot devices — ESP and boot pool

A ZFS-on-root system needs two things outside the main pool: an EFI System Partition (ESP) for the bootloader, and optionally a small boot pool if your bootloader can't read ZFS directly. kldload uses a direct ZFS boot chain (kernel + initramfs on the root pool), so you only need the ESP.

Mirror your boot devices

If your single boot SSD fails, the system won't boot even though the ZFS pool is healthy on other disks. Mirror the ESP across two devices. For a dedicated boot setup, two small SSDs (120–256GB) in a ZFS mirror work perfectly. For an integrated setup, partition the first two data disks with a small ESP partition each and use efibootmgr to register both.

# kldload automatically mirrors the ESP across available disks
# To verify ESP mirrors:
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT | grep -i efi

# Manual ESP mirror (if needed):
# 1. Create matching ESP partitions on both disks
# 2. Format both as FAT32
# 3. Copy bootloader files to both
# 4. Register both with efibootmgr:
efibootmgr -c -d /dev/sda -p 1 -L "Linux Boot 1" -l '\EFI\BOOT\BOOTX64.EFI'
efibootmgr -c -d /dev/sdb -p 1 -L "Linux Boot 2" -l '\EFI\BOOT\BOOTX64.EFI'

CPU requirements

ZFS is not CPU-intensive for basic operations, but specific features have real CPU requirements. Any modern x86_64 processor handles ZFS fine. The features that demand CPU attention are compression, encryption, and deduplication.

# Verify CPU feature support
grep -o 'aes\|sha_ni\|avx2\|sse4_2' /proc/cpuinfo | sort -u
# aes      — required for native ZFS encryption at full speed
# sha_ni   — accelerates SHA-256 checksumming and dedup
# avx2     — accelerates various ZFS operations
# sse4_2   — CRC32 acceleration for checksumming

Power protection — UPS is mandatory

Beyond ZIL safety, a UPS protects against:

# Install and configure UPS monitoring (APC example)
dnf install apcupsd     # RHEL/CentOS/Fedora/Rocky
apt install apcupsd     # Debian/Ubuntu

# /etc/apcupsd/apcupsd.conf — key settings:
# UPSTYPE usb
# UPSCABLE usb
# TIMEOUT 60          — shutdown after 60 seconds on battery
# BATTERYLEVEL 15     — shutdown when battery reaches 15%
# MINUTES 5           — shutdown when 5 minutes of runtime remain

# For Network UPS Tools (NUT):
dnf install nut         # supports more UPS brands than apcupsd
# Configure /etc/ups/ups.conf, /etc/ups/upsd.conf, /etc/ups/upsmon.conf

Backplanes, expanders, and disk shelves

When you need more drives than your HBA's port count, you have three options: SAS expanders, multiple HBAs, or external disk shelves (JBODs).

Drive count vs redundancy

More drives means more failure probability. A pool with 24 drives is far more likely to experience a drive failure in any given year than a pool with 4 drives. The Annualized Failure Rate (AFR) compounds: if each drive has a 1% AFR, a 24-drive pool has a ~21% chance of at least one failure per year. This is why redundancy level must scale with drive count.

Recommended builds by use case

Home NAS — 4–8 bay, budget-conscious

Production file server — 12–24 bay, enterprise-grade

All-flash pool — maximum IOPS, minimum latency

Verify your hardware

# Verify HBA is in IT mode (not RAID mode)
lspci -v | grep -i "LSI\|Broadcom\|SAS"
# Should show "Serial Attached SCSI controller" — NOT "RAID bus controller"

# Verify disks are directly visible (not behind RAID)
ls -l /dev/disk/by-id/
# Should show scsi-* or ata-* entries for each physical disk

# Verify ECC RAM is active
edac-util -s        # shows ECC error counts (install edac-utils)
dmidecode -t 17 | grep -i "error correction"
# Should show "Multi-bit ECC" or "Single-bit ECC"

# Verify AES-NI and SHA-NI support
grep -o 'aes\|sha_ni' /proc/cpuinfo | sort -u

# Check for SMR drives
smartctl -a /dev/sdX | grep -i "rotation rate\|form factor"
# Also check manufacturer's spec sheet — smartctl doesn't directly report SMR

# Verify drive health
smartctl -H /dev/sdX
# PASSED = healthy, FAILED = replace immediately

# Check SSD wear
smartctl -a /dev/nvme0n1 | grep -i "percentage used"
# Percentage Used: 3% — drive is at 3% of rated endurance

# Verify UPS is communicating
apcaccess status     # for APC UPS with apcupsd
upsc myups@localhost # for NUT

Hardware checklist