Buying a hard drive used to be simple: you looked at capacity, RPM and interface, and that gave you a clear idea of its performance. For a few years now there has been an invisible variable that can change everything: the magnetic recording technology. Two units identical in capacity and form factor can hide two completely different internal architectures, CMR and SMR, with enormous consequences for write performance.
The problem is that many manufacturers do not state it on the box or in the product name. An administrator can build an array believing they bought server-grade drives and discover, weeks later and at the worst possible moment, that their RAID rebuild is not progressing because the drives are SMR. In this article we explain what sets CMR apart from SMR, why SMR is poison for write-heavy workloads and RAID, where it does make sense, and how to detect it before you buy.
If you have just decided which interface to use, this article is the natural companion to our guide on SATA, SAS and NVMe: the interface sets the performance ceiling, but the recording technology determines whether the drive meets that ceiling in a sustained way.
CMR: Conventional Recording, Tracks That Never Overlap
CMR (Conventional Magnetic Recording) is the classic way of writing data on a hard drive. The platters are divided into concentric tracks and each track is written independently and without overlapping its neighbours, leaving a small guard band between them. The write head is wider than the read head, but because it does not invade the adjacent track it can rewrite any sector without affecting the data next to it.
That independence between tracks is precisely what gives CMR its great virtue: predictable, constant random-write performance. It does not matter whether the workload is sequential or scattered, whether the drive is empty or nearly full: the behaviour stays stable over time, with no surprises. That is why CMR (sometimes called PMR, Perpendicular Magnetic Recording, of which it is a variant) is the reference technology for enterprise drives, NAS units and any disk destined for an array.
The price of this reliability is density. The guard bands between tracks waste platter surface, which limits how many terabytes fit on the same number of platters. To squeeze out more capacity without raising manufacturing cost, the industry looked for an alternative. That alternative is SMR.
SMR: Tracks Overlapped Like Roof Shingles
SMR (Shingled Magnetic Recording) starts from a clever idea: since the read head is narrower than the write head, you do not need to leave so much space between tracks. SMR writes tracks partially overlapped, like the shingles on a roof (hence "shingled"). Each new track covers one edge of the previous one, leaving visible only the band needed for the read head to recover the data.
The result is noticeably higher density: more terabytes fit on the same number of platters, which translates into a lower cost per TB. For the manufacturer it is a cheap way to offer very high-capacity drives, and for mass archival it can be a bargain. The problem appears when you have to modify data that is already written.
Because the tracks overlap, you cannot rewrite an isolated track without damaging the ones on top of it. Tracks are grouped into bands (zones) and, to change a single sector, the drive has to read the whole band, modify it in memory and write it back in full. That write amplification is SMR's Achilles heel and the root of all the problems we are about to see.
The Problem: Sustained Random Writes
An SMR drive behaves well while it writes sequentially, or while there are short write bursts that fit in its cache zone (an internal region managed as CMR that temporarily absorbs the data). The deception starts as soon as the write workload becomes random and sustained: the cache fills up, the drive has to start reorganising whole bands in the background, and performance collapses.
We are not talking about a moderate drop. An SMR drive that wrote at more than 100 MB/s sequentially can fall to just a few MB/s once the internal reorganisation kicks in, with unpredictable latencies ranging from milliseconds to several seconds per operation. Worse still: those stalls do not show up in a short benchmark. They only appear under prolonged load — exactly what happens on a production server, not on the test bench where the drive was validated.
The key thing to understand:
SMR is not "slow" all the time. It is unpredictable under sustained random writes. A drive that performs perfectly in your 30-second test can collapse after hours of continuous writing — precisely when you rebuild an array or restore a large backup.
Types of SMR: DM, HM and Host-Aware
Not all SMR is the same, nor equally dangerous. There are three variants depending on who manages the complexity of the overlapping bands:
- check_circle Drive-Managed (DM-SMR): the drive completely hides its SMR nature from the operating system and manages band reorganisation internally. It behaves like a normal disk... until it saturates. It is the most dangerous because it is indistinguishable from a CMR drive at a glance and it is the one that tends to slip into consumer drives without warning.
- check_circle Host-Managed (HM-SMR): the drive exposes its zones to the system, which must write strictly sequentially within each band. It requires prepared software and file systems, but in exchange it delivers predictable performance. It is the "honest" SMR, used by hyperscalers and mass archives designed for it.
- check_circle Host-Aware: a hybrid. The drive works like a conventional one, but it also reports its zone structure so a prepared system can optimise writes. It combines compatibility with the option of better performance if the host cooperates.
DM-SMR is the one that causes 99% of the headaches, precisely because its design goal is to go unnoticed. And that brings us to the episode that put the problem on the map.
The 2020 Scandal and Why SMR Ruins a RAID
In 2020 the controversy broke: several manufacturers had slipped unlabelled DM-SMR drives into NAS-oriented ranges — precisely the drives people buy to build arrays. Users found out the hard way. When they replaced a failed disk and launched the RAID rebuild (or the resilvering in ZFS), the process never finished, slowed down to absurd levels, or the controller dropped the disk on a timeout, leaving the array degraded and at real risk of data loss.
The reason is direct: rebuilding an array is one of the most intense and prolonged random-write workloads that exists. You are rewriting entire terabytes of parity or replica data in a sustained way over hours or days. It is exactly the kind of load that makes an SMR drive collapse. What on a CMR drive is a few hours of rebuild becomes, on a DM-SMR, an endless process that also keeps the array vulnerable the whole time. If you want to dig deeper into how these processes work, we have a complete RAID guide and another on how ZFS protects your data.
ZFS was especially sensitive to the problem. Its resilvering combines reading and writing metadata in a very scattered way, a pattern that saturates the SMR's internal cache almost immediately. Many administrators documented rebuilds that went from hours to more than a week, or that simply failed. The community's conclusion was unanimous and still stands: SMR and RAID/ZFS do not get along. Large-scale drive reliability analyses, such as those published by Backblaze on its blog, reinforce the idea of sizing storage while knowing the real technology behind each unit.
Where SMR Does Make Sense
None of this means SMR is a bad technology. It is a technology that is badly applied when it is sneaked into workloads it was not built for. In its niche, SMR's low cost per TB is a legitimate advantage. The scenarios where it genuinely fits:
- check_circle Cold sequential archival: data written once, in order, and kept for years with very infrequent access. There is no random rewriting here to penalise.
- check_circle WORM schemes (Write Once, Read Many): compliance repositories, legal evidence or historical records that are written once and then only read.
- check_circle Large-volume backup without constant rewriting: backup chains deposited sequentially onto a capacity target, where price per TB rules and scattered writes are minimal.
- check_circle Video surveillance: video streams recorded continuously and sequentially from several cameras — a pattern that is friendly to SMR and hungry for cheap capacity.
How to Identify an SMR Drive Before Buying
The good news is that, after the 2020 controversy, manufacturers are far more transparent. Even so, it is worth checking every time before you buy. The most reliable ways:
- arrow_right Manufacturer datasheet: look for the "recording technology" field. If it says SMR, you know; if it says CMR/PMR, it is safe for RAID. If it does not state it and the drive is very high capacity and suspiciously cheap, be wary.
- arrow_right Community lists: there are community-maintained tables (NAS, ZFS and storage forums) that collect which specific models and part numbers are SMR. They are especially useful for older drives or ambiguous ranges.
- arrow_right Range and exact part number: within the same product family there can be CMR and SMR part numbers. Do not trust the series name: verify the full part number.
Comparison Table: CMR vs SMR
A summary of the differences that matter when deciding which drive goes where:
| Criterion | CMR (conventional) | SMR (shingled) |
|---|---|---|
| Sustained random write | Constant and predictable | Collapses once cache saturates |
| Latency under load | Stable | Unpredictable (second-long spikes) |
| Suitable for RAID / ZFS | Yes | No (problematic rebuild) |
| Suitable for production NAS | Yes | Sequential workloads only |
| Density / capacity | High | Higher (more TB/platter) |
| Cost per TB | Medium | Lower |
| Ideal use | Servers, RAID, databases, NAS | Cold archive, WORM, surveillance |
EasyDataHost: CMR in Production, Storage Sized to the Workload
At EasyDataHost we apply a simple rule: for production RAID configurations, we require CMR. Our storage servers are built with verified conventional-recording drives, precisely so that a disk replacement or an array rebuild resolves in hours and does not turn into a nail-biting weekend.
When a project genuinely fits SMR (cold sequential archival, large WORM repositories, video surveillance), we use it consciously and documented, taking advantage of its lower cost per TB where it really adds value. The difference is not leaving it to chance: we size storage according to the real workload pattern, not according to what the label on the box says.
All of it on our own infrastructure in Spain, with ISO 27001 certification and ENS compliance. If you are not sure which technology your workload needs, contact our team for a technical analysis with no obligation.
Frequently Asked Questions
How do I know if a hard drive is SMR or CMR?
It is not always labelled. Check the manufacturer's datasheet for the recording technology field (SMR/CMR or "recording technology") and rely on the community-maintained lists that track affected models. As a rule, be suspicious of unusually cheap high-capacity consumer drives and prioritise enterprise or NAS models that explicitly state CMR.
Can I use SMR drives in a RAID or in ZFS?
It is not advisable. Rebuilding an array (resilvering in ZFS) generates sustained random writes, exactly the workload that collapses an SMR drive. The rebuild can take days or cause the controller to drop the disk on a timeout, leaving the array degraded. For production RAID and ZFS, always use CMR.
What is an SMR drive good for, then?
For sequential-write, read-often workloads: cold archival, WORM schemes (write once, read many), large-volume backup without constant rewriting and video surveillance. In those scenarios SMR's lower cost per TB is a genuine advantage and its penalties are barely noticeable.
Conclusion
SMR and CMR solve the same problem (storing data on magnetic platters) with opposite philosophies: maximum cheap capacity versus maximum predictability. Neither is "better" in the abstract; what is dangerous is confusing them, or having one slipped to you without knowing:
- arrow_right CMR offers constant, predictable random writes. It is the mandatory choice for servers, databases, production NAS and any RAID or ZFS array.
- arrow_right SMR wins on density and cost per TB, but it collapses under sustained random writes. Reserved for cold sequential archival, WORM, mass backup and video surveillance.
- arrow_right Never put SMR in a production RAID: the rebuild can take days or fail, leaving your array degraded exactly when you need it most.
- arrow_right Always verify the recording technology before buying, checking the manufacturer datasheet and the exact part number, not just the range name.