The SMR Drive Trap: Slow ZFS and How to Avoid It

You build a RAIDZ1 pool with four new NAS drives, and the first scrub drags into its third day. zpool status shows a drive repeatedly disconnecting and reconnecting while SMART stays spotless. The problem isn’t a bad batch — it’s shingled magnetic recording (SMR).

What Shingled Magnetic Recording Actually Does

Shingled magnetic recording (SMR) overlaps tracks like roof shingles. The write head is wider than the final track, so writing a new track partially overwrites the adjacent one. Reading remains straightforward, but writing becomes destructive: to update one shingled track, the drive must read all overlapping downstream tracks, rewrite them, and then write the new data. This is invisible to the host.

Drive-managed SMR (DM-SMR) hides the complexity behind firmware, using a small CMR-cache zone for incoming writes. Under light, bursty loads the cache never fills and performance looks normal. Under sustained load, the cache overflows and the drive must reorganize shingled zones in real time. Latency spikes from milliseconds to seconds.

Why ZFS and SMR Are Fundamentally Incompatible

ZFS writes data in transaction groups — collecting dirty blocks every few seconds and issuing large sequential writes to new locations. That copy-on-write pattern is brutal on SMR drives. The mixed stream of random metadata and sequential data fills the drive’s CMR cache quickly, and ZFS never pauses long enough for the drive to flush it. Within minutes, the cache overflows.

Once the cache fills, the drive must reorganize shingled zones on every write. Latency jumps from under 10 ms to 2,000 ms or more. ZFS, expecting sub-second completion, times out I/O. A single stalled transaction group can hang the entire pool, and if a drive misses enough commands, ZFS marks it faulted and detaches it — even though the disk is physically fine.

Resilvering is the worst-case. ZFS sequentially writes the entire replacement drive while reading from healthy ones. On CMR, that finishes in 8–12 hours. On DM-SMR, the drive constantly garbage-collects shingled zones, stretching the process to 4 days. Meanwhile, latency on the reading drives spikes, and if a second drive times out during a RAIDZ1 resilver, the pool is gone.

The WD Red SMR Scandal and Other Offenders

In 2020, Western Digital shipped DM-SMR platters in several WD Red NAS models without disclosure — WD20EFAX, WD30EFAX, WD40EFAX, WD60EFAX. NAS buyers expected sustained write tolerance and got drives that couldn’t handle RAID rebuilds. After backlash, WD split the Red line: plain Red drives up to 6 TB are SMR; Red Plus and Red Pro are CMR. An EFAX suffix on a 2–6 TB Red is a warning sign.

Seagate Barracuda Compute (ST4000DM004, ST8000DM004) and some Toshiba P300 drives also shipped SMR without clear labeling. The lesson: neither “NAS” branding, spindle speed, nor cache size tells you the recording technology. Check explicitly.

How to Check Whether a Drive Is SMR Before You Buy

Manufacturer spec sheets

Sometimes the recording method is listed in fine print. WD’s product page may state “Recording Technology: CMR.” Seagate mentions it in datasheet PDFs. Toshiba N300 explicitly states CMR. If the spec sheet is silent, assume SMR.

Community-maintained databases

The r/DataHoarder wiki maintains a CMR/SMR drive list. ServeTheHome forums have a sticky thread with confirmed models. Check these before buying, because manufacturers have reclassified models without changing model numbers in the past.

Known-good CMR models (quick reference table)

Always verify the exact model number. A WD Red 4 TB could be WD40EFAX (SMR) or WD40EFZX (CMR). The suffix is what matters.

If You Already Have SMR Drives in a ZFS Pool

First, identify what you have. Check the model string from the device symlink:

ls -l /dev/disk/by-id/ | grep -E 'ata-|scsi-' | grep -v part

Alternatively, pull it from SMART:

smartctl -a /dev/sdX | grep "Device Model"

Compare the model against community lists. Symptoms are predictable: 72+ hour scrubs on a 4 TB pool, drives briefly faulting then re-onlining, and kernel logs full of task abort or WRITE FPDMA QUEUED timeouts.

Realistic mitigation is limited. Keep pool usage under 80% and write large files sequentially, but ZFS’s copy-on-write inherently fragments free space. Reducing scrub frequency helps, but the next resilver or heavy write burst will still hit the SMR wall. Never place an SMR drive in a RAIDZ vdev: if it stalls on a read, it can block the entire stripe and cascade to other drives. The only safe configuration for SMR is a single-disk pool with no redundancy — which defeats the point of ZFS.

Replacement is the only real fix. Move the SMR drives to a backup pool or use them as cold storage with a filesystem that does infrequent large writes.

What to Buy Instead: CMR Drive Recommendations for ZFS

NAS and enterprise lines that guarantee CMR are the safest bet. WD Red Plus and Red Pro are CMR across all current capacities. Seagate IronWolf (non-Pro) drives are CMR; IronWolf Pro adds vibration sensors and longer warranty. Toshiba N300 is CMR and often competitively priced.

For budget builds, used enterprise SAS drives are an option. HGST Ultrastar, WD Gold, and Seagate Exos drives are almost universally CMR, built for sustained 24/7 workloads, and available decommissioned at $10–15/TB. The trade-off: SAS HBAs are required, power draw is higher (7–10 W idle vs 4–6 W for NAS drives), and they’re noticeably louder. If noise or electricity costs matter, stick with NAS-class CMR drives.

Even within these lines, verify model numbers before purchase. A quick search for “ CMR SMR” before buying is cheap insurance against a multi-day resilver.

The rule is simple: don’t put SMR drives in a ZFS pool. DM-SMR is a desktop technology that breaks under the sustained random-write workload ZFS generates. Getting it wrong means scrub times measured in days, false drive faults, and resilvers that risk the entire pool. The fix isn’t a ZFS tuning parameter — it’s buying drives with conventional magnetic recording. Check model numbers, consult the databases, and if you have SMR drives now, plan their migration. The time spent verifying recording technology is nothing compared to the time lost waiting for an SMR drive to finish a routine scrub.