This isn’t an obscure edge case. It’s happened at scale, publicly, more than once - manufacturers quietly shipping SMR drives in product lines everyone assumed were CMR, and the data hoarding and NAS communities finding out the hard way when arrays started misbehaving. If you’re buying drives for a NAS, a ZFS pool, or any kind of RAID array, this is one of the few things worth actually understanding before you buy, not after.

What CMR and SMR actually are

Both are ways of laying down data tracks on a spinning hard drive platter. The difference is how those tracks are arranged.

CMR (Conventional Magnetic Recording) writes tracks side by side with a small gap between them, like lanes on a highway. Each track can be rewritten independently without touching its neighbors. This is how hard drives have worked for decades, and it’s what you want for anything involving RAID, ZFS, or sustained random writes.

SMR (Shingled Magnetic Recording) overlaps tracks like roof shingles, packing them closer together to squeeze more capacity onto the same platter. The catch: because tracks overlap, writing to one track can require rewriting the tracks next to it too. Drive firmware manages this with a caching and write-amplification scheme that works fine for sequential, low-churn workloads (think: dumping a large backup file once and mostly reading it back) and falls apart under sustained random writes, exactly the kind of workload a RAID rebuild or a ZFS resilver generates.

SMR isn’t a scam by itself. It’s a real engineering tradeoff that makes sense for some workloads (cold archival storage, sequential write-once-read-many data, some surveillance/DVR use cases). The problem is when it ends up in a drive marketed for NAS use, or in a role like an array member, without anyone being told.

Why this specifically wrecks RAID and ZFS

A RAID rebuild or a ZFS resilver reads every surviving drive and writes reconstructed data back to the replacement drive, and that write pattern is neither purely sequential nor small. On a CMR drive, this is a straightforward, if lengthy, sustained operation. On an SMR drive, the firmware’s shingled-write translation layer chokes under sustained write pressure. What actually happens in practice:

• Rebuild times balloon from hours to days, sometimes far beyond what the array controller or ZFS’s own timeout expectations assume.
• Some RAID controllers time out and drop the SMR drive entirely mid-rebuild, because it looks unresponsive rather than just slow - which can turn a single-drive failure into a failed rebuild with a second “failure” that isn’t actually a hardware failure at all.
• ZFS resilvers on SMR drives have been documented taking dramatically longer than the same job on CMR drives of the same capacity, and can trigger drive timeout errors that look like hardware faults in the logs.

The nasty part is that none of this shows up when the drive is new, mostly empty, and being written to sequentially. It shows up specifically when you need the drive to perform under stress: during a rebuild, which is exactly the moment your array has the least margin for another problem.

How manufacturers use the term (and don’t)

The reason this catches people off guard is that “NAS drive” and “SMR” are not mutually exclusive marketing claims, and for a while, manufacturers weren’t consistently disclosing which recording technology a given drive model used. The most well-known incident: several major manufacturers were found to have silently swapped some models in existing drive lines from CMR to SMR without changing the model number, discovered by the community running write-performance benchmarks on drives that suddenly performed very differently from earlier units with the same label on the box.

That specific incident forced the industry to be more transparent, and today reputable manufacturers publish CMR/SMR specification pages you can check by exact model number before buying. But the underlying lesson holds: don’t assume a drive is CMR just because it’s marketed as a NAS or surveillance drive, and don’t assume a model number you bought before still matches a model number you’re buying today. Product lines get revised.

How to check before you buy

• Look up the exact model number, not just the family name, on the manufacturer’s own published CMR/SMR drive list before ordering.
• Check capacity and drive class as a rough filter, not a guarantee. SMR has historically shown up more often in the cheapest drives in a given capacity tier and in some external/USB drives repackaging a bare internal drive, but exceptions exist in both directions, so this is a starting point for suspicion, not a substitute for checking the model number.
• If a drive is unusually cheap for its capacity compared to its peers, that’s worth a specific check, not an automatic red flag - sometimes it’s just a sale, but SMR is one of the reasons a drive can be priced meaningfully below CMR competitors at the same capacity.
• Community drive databases and forum megathreads (r/DataHoarder and r/homelab both maintain running lists) are a fast way to sanity-check a specific model before you commit to an order, especially for older or less common models where the manufacturer’s own page may be harder to find.

What to do if you already have SMR drives in an array

You’re not necessarily doomed, but you should know what you’re carrying:

• Don’t mix SMR and CMR drives in the same redundant vdev/array if you can avoid it. A rebuild is only as fast as its slowest participant, and a single SMR drive in an otherwise-CMR array drags the whole operation out and adds risk for everyone.
• If you’re stuck with SMR drives, treat rebuild windows as higher-risk events. Don’t kick off a rebuild right before you’re going to be away from the system for a while, and keep a closer eye on zpool status or your RAID controller’s status than you normally would during the rebuild.
• SMR is genuinely fine for some roles: a single-drive backup target you write to sequentially and rarely touch, cold archival storage, or a drive that’s never part of a redundant array’s rebuild path. The problem is specifically the RAID/ZFS array-member role, not SMR technology in general.
• When it’s time to replace a drive, replace it with CMR, even if it costs somewhat more per terabyte. For an array member, the rebuild-time and rebuild-reliability difference is worth the premium.

The one-line takeaway

CMR and SMR aren’t a “better vs. worse” hard drive story in general - they’re two different tools for two different jobs. The mistake isn’t buying an SMR drive. The mistake is putting one into a RAID or ZFS array without knowing that’s what you bought, and finding out during the one moment - a rebuild - when it matters most.