Two drives can carry the same capacity, the same interface and a nearly identical price tag, yet behave completely differently inside a RAID array. The variable is usually the recording technology: CMR or SMR. It is rarely printed on the box, and it is the single most expensive thing to get wrong in a volume order.
What the two acronyms actually mean
CMR — Conventional Magnetic Recording — is the classic layout. Data tracks are written in parallel, side by side, with a small gap between them. Because no track touches its neighbour, the drive can write to any track at any time without touching the others.
SMR — Shingled Magnetic Recording — packs tracks closer together by allowing each one to overlap the edge of the previous one, like roof shingles. Overlapping tracks lets the manufacturer fit more of them onto the same platter, which raises capacity. Industry figures for the density gain generally land in the region of 15–25% for the same media.
Reading is not the problem. Read heads are physically narrower than write heads, so a read head can still address a single track without disturbing its neighbours. The complication is entirely on the write path.
Why writing to an SMR drive is different
Because each track overlaps the one beneath it, writing a track destroys part of the adjacent track. To change one track safely, the drive has to read the surviving fragments of its neighbours, merge in the new data, and write the whole group back. This read-modify-write cycle is invisible to the operating system but very real in terms of time: a single random write can become several operations.
The narrow strip of tracks that must be rewritten together is called a band. Writing sequentially within a band is fast — it is close to native speed. Jumping around between bands is not.
Manufacturers paper over this with a persistent cache: a reserved area of the disk that absorbs random writes in their original form, then flushes them back into the shingled layout later, when the drive is idle. On a light workload this works well and the user never notices.
On a heavy, sustained random-write workload it does not. Once the cache region fills, the drive must flush before it can accept more, and throughput can collapse to a fraction of its rated speed. This cliff is the reason SMR drives have a reputation problem.
Where SMR is fine, and where it is not
SMR is genuinely well suited to workloads that write in large sequential streams and read occasionally:
- Cold and archive storage — data written once and rarely touched.
- Backup targets — large sequential writes, with restore traffic that is read-mostly.
- Media libraries and video archives — big files, written whole.
- Surveillance recording — continuous sequential write streams.
It is a poor fit for anything involving sustained random writes:
- RAID rebuilds — the critical case, explained below.
- Databases and virtual machines — small, scattered, frequent writes.
- Multi-user file servers — many simultaneous writers, no predictable order.
- Write-heavy logging or transactional workloads.
The RAID rebuild problem
This is the scenario that turns a specification detail into an operational risk. When a drive in a RAID array fails, the replacement has to be rebuilt from parity — hours to days of continuous, intense, largely random write traffic, for the entire duration of the rebuild.
That is precisely the workload an SMR drive handles worst. The persistent cache saturates almost immediately, and rebuild throughput can drop far below the drive’s rated sequential speed. In an array of large drives, a rebuild that should take a day can stretch out considerably — and the longer the array runs degraded, the wider the window in which a second failure would be unrecoverable.
Some controllers also time out drives that stop responding within a fixed interval. A drive that is busy flushing its cache can exceed that window and be dropped from the array, which is a far worse outcome than slow performance.
Why you often cannot tell from the label
Recording technology is rarely part of the marketing name. A drive family can contain both CMR and SMR members with sequential-looking model numbers. This ambiguity became a public issue when a major manufacturer shipped SMR drives inside a NAS-oriented product line without disclosing it; the resulting backlash pushed the industry towards clearer labelling, but the practice of checking specs rather than trusting a name still applies.
Where to look:
- The datasheet — look for a “recording technology”, “CMR” or “SMR” field in the specification table.
- The manufacturer’s NAS compatibility list — vendors publish which models are validated for multi-bay use. Absence from that list is a signal.
- The model number suffix. Some vendors use distinct suffixes for the SMR variant of an otherwise identical drive.
- Ask the supplier, in writing. This is the point of the whole article. A supplier who cannot answer the question either does not know their stock or does not want to say.
What to do when you are ordering in bulk
- State the workload, not just the capacity. “We need 200 × 16TB for a Ceph cluster” and “we need 200 × 16TB for an archive tier” have different correct answers.
- Require CMR in writing for any RAID, NAS or virtualisation deployment. Put it on the purchase order.
- Accept SMR where it genuinely fits. For cold archive tiers it can reduce cost per terabyte with no practical downside.
- Test before you scale. Rebuild one array with the candidate drive and time it. A single-array test costs far less than discovering the answer during a production incident.
- Keep the same recording technology across an array. Mixing CMR and SMR members within one RAID set produces unpredictable rebuild behaviour.
Conclusion
SMR is not a defective technology. It is a deliberate trade: density in exchange for write behaviour, and it is the right trade for archive and sequential workloads. The failure mode is not the technology itself but buying it without knowing — and then discovering what it is during a rebuild at three in the morning.
One question on the purchase order removes the entire risk.
