Shingled recording is a genuinely good deal: more capacity from the same platters, for less money per terabyte. It's also the single most misunderstood spec on a hard drive's box, and getting it wrong is how a routine RAID rebuild turns into a multi-day outage. Here's how SMR actually works, what "managed" really means, what happens when nobody's managing it, and why HuskHoard's user-space daemon is the right place to do the managing.
Fundamentals
Every hard drive has a fundamental asymmetry between its read and write heads. Flipping the magnetic polarity of a spot on a platter takes a comparatively strong field, so the write head has to be physically wide enough to generate one. Sensing that same spot's polarity to read it back takes far less — modern read heads can be built dramatically narrower than the write head that put the data there in the first place.
Conventional drives — CMR, for Conventional Magnetic Recording — deal with this by spacing tracks apart wide enough that the write head's full footprint fits between them with room to spare. Every track is a fully independent lane. You can rewrite track 400 without touching track 399 or track 401 at all.
Shingled Magnetic Recording - SMR, throws that spacing away. Each new track is written so it partially overlaps the track before it, the way each course of shingles on a roof overlaps the course below it. The result is a much narrower effective track pitch, because what actually gets read back is only the sliver of each track that wasn't paved over by its neighbor. Pack the tracks tighter, and more of them fit on the same platter — that's the entire mechanism SMR uses to buy extra capacity for free from the same physical media.
The CMR model
Every track stands alone
Tracks are spaced with a gap wide enough for the write head. Rewriting any single track is a self-contained operation — it never disturbs the tracks on either side of it.
The SMR model
Tracks overlap like shingles
Each track is laid down partially on top of the last one. That's what shrinks the pitch and buys the density — but it also means writing to a track destroys the part of the neighboring track it overlaps, unless something rewrites that whole overlapping run in order.
That last sentence is the entire story of SMR. It is a fantastic trade of write flexibility for density — as long as something, somewhere, respects the order those overlapping tracks have to be written in. Whether that "something" is the drive's own firmware or the host operating system is exactly what the word "managed" refers to, and it's the difference between a drive that behaves and one that quietly ruins your afternoon.
Three Ways an SMR Drive Can Be Managed
"SMR" on a spec sheet doesn't tell you who is responsible for respecting the shingle order. That's a separate axis entirely, and it's the one that actually determines whether the drive is safe to put into your workflow unmodified.
DM-SMR
Drive-Managed
The firmware hides the shingling entirely and presents an ordinary block device that accepts random writes anywhere, just like a CMR drive. Internally, it buffers incoming writes in a small conventional (unshingled) cache region and quietly reorganizes shingled bands in the background. Fully backwards compatible with any OS, controller, or RAID card — and completely opaque about when and how hard that background reorganization is working.
HA-SMR
Host-Aware
A hybrid: the drive exposes zone information and accepts explicit zone commands from a cooperative host, but it will still accept out-of-order random writes if the host doesn't bother. Host-aware drives were positioned as a transitional format and are uncommon in current product lines — most vendors have settled on strictly drive-managed or strictly host-managed.
HM-SMR
Host-Managed
The drive enforces zone rules at the command level and simply rejects anything that violates them. Writes to a zone must land exactly at that zone's current write pointer, in order, every time. There is no firmware translation layer, no hidden cache, and no ambiguity — the host operating system and the software above it take on full responsibility, addressed via the ZBC (SAS) or ZAC (SATA) command sets, or ZNS on NVMe.
Checking
Which One Do You Actually Have
The retail box rarely says. On Linux, lsblk -o NAME,ZONED reports host-managed or none, and smartctl -a /dev/sdX will usually surface the zoned device model. If neither says "zoned," and it's a spinning drive shipped after roughly 2015, don't assume — a good number of drive-managed models never advertise SMR at all.
The failure mode that made this famous
In 2020, independent testers discovered that several major manufacturers had been quietly shipping drive-managed SMR models inside NAS-branded product lines — without disclosing it on the spec sheet. Owners running RAID and ZFS arrays started seeing rebuilds that should take hours stretch into days, because a rebuild is exactly the sustained-write workload that DM-SMR firmware handles worst. It's the reason "is it actually SMR, and which kind" became a question storage-conscious buyers now ask before every purchase.
Zones, Write Pointers, and the One Rule You Can't Break
On a host-managed drive, capacity isn't one flat address space — it's divided into zones, typically 256MB, each of which is a strict sequential-write region. Every zone has exactly one thing it tracks about itself: a write pointer, marking the next address that's legal to write to. You can append at the pointer. You cannot write anywhere else in that zone. Try, and the drive returns an error instead of touching the platter.
A zone moves through a small number of states over its life, and the entire host-managed contract is about respecting that lifecycle instead of fighting it.
01
Zone is Empty
Write pointer sits at the start of the zone. No data has been written since the last reset. This is the only state a zone can be written into for the first time.
02
Zone Opens on First Write
A zone_append lands at the write pointer. The zone transitions to Open, and every subsequent write must continue from wherever the pointer now sits — never before it, never after a gap.
03
Sequential Appends Advance the Pointer
Each write advances the pointer by exactly the number of blocks written. This is the only legal way the pointer moves — there is no seek, no random write, no partial rewrite of an already-written block.
04
Zone Fills, Finish or Full
Once the pointer reaches the end of the zone, it's Full. No further writes are accepted, even if the data inside it is later deleted at the filesystem level — deletion doesn't reclaim space in a sequential zone.
05
Reset Write Pointer
The only way to reclaim a Full zone is to reset it — effectively a per-zone trim that discards everything in it and returns the pointer to the start. There is no in-place rewrite; reclaiming space is always all-or-nothing per zone.
// What the drive actually enforces on a host-managed zone
fn zone_append(zone: &mut Zone, data: &[u8]) -> Result {
if zone.state == ZoneState::Full {
return Err(Error::NoSpace); // zone must be reset first
}
// there is no "offset" argument — you cannot target an address,
// only append at wherever the pointer currently sits
let write_addr = zone.write_pointer;
device.write_at(write_addr, data)?;
zone.write_pointer += data.len() as u64;
if zone.write_pointer == zone.end {
zone.state = ZoneState::Full;
}
Ok(write_addr)
}
// A naive filesystem trying to update a block in the middle of the zone:
device.write_at(zone.start + 4096, patch_bytes)
// → Error: Invalid argument (writes must target the current write pointer)
Notice what's missing from that error: any mention of what went wrong at a higher level, or any attempt by the drive to fix it for you. Host-managed drives don't negotiate. That's the whole point — and it's exactly why nothing should be allowed to write to one without knowing the rule above by heart.
What Goes Wrong When SMR Isn't Managed Properly
Both flavors of SMR fail badly when they're mismatched with the workload sitting on top of them — they just fail in different, equally unpleasant ways.
01
The Drive-Managed Performance Cliff
DM-SMR firmware buffers incoming writes in a small conventional cache region and reorganizes shingled bands behind your back. That works fine for bursty, everyday traffic — until sustained writes fill the cache faster than the background reorganization can drain it. Throughput then falls off a cliff, sometimes by an order of magnitude, with no counter or log line warning you it's about to happen.
02
RAID Rebuild Time Bombs
A RAID or ZFS rebuild is one enormous sustained sequential write across the entire replacement drive — precisely the pattern that triggers the DM-SMR cliff. Rebuilds that should take hours can stretch into days, and every one of those extra hours is spent with the array running degraded, where a second drive failure turns an inconvenience into real data loss.
03
Host-Managed Drives Just Refuse
Point a zone-unaware filesystem, an old LVM layer, or a naive application at an HM-SMR drive, and you don't get a slowdown — you get outright I/O errors the moment anything tries a random or out-of-order write. That's often triggered by the most ordinary operations: extending a fragmented file, or updating a journal in place.
04
Garbage Collection Storms
Let several concurrent writers land in different zones without any coordination, and you fragment work across many partially-full zones at once. On a drive-managed disk, that multiplies background reclamation work everywhere simultaneously; the drive can appear to hang under load that a CMR disk would shrug off.
The Density Payoff: Why Bother With Any of This
Given everything above, it's fair to ask why anyone deals with SMR at all. The answer is that the density gain is real and it's substantial — shingled tracks routinely pack roughly 15–20% more areal density onto the same platters and read/write heads as the conventional drive sitting one generation behind it. Same manufacturing process, same number of platters, meaningfully more usable capacity per drive.
A
CMR, same generation
Independently addressable tracks, spaced for the full width of the write head. Areal density is capped by that spacing.
baseline
B
SMR, same platters
Overlapping tracks shrink the effective pitch and raise areal density roughly 15–20% on identical physical media — the extra capacity isn't coming from more platters or a different substrate, purely from packing the same media tighter.
host-managed
That density gain doesn't move manufacturing cost much — it's largely the same platters, heads, and motor as the CMR sibling. What it moves is cost per usable terabyte, because you're getting meaningfully more terabytes out of roughly the same bill of materials. At the scale of a single desktop drive, that's a modest saving. At archive scale — racks of drives holding hundreds of terabytes or more — it compounds into a real difference in what an archive costs to build and to keep running.
The catch is that this payoff is conditional. You only get to keep the density gain if whatever writes to the drive respects the sequential contract the density was bought with — either by trusting DM-SMR firmware to handle it invisibly (with the risks from the previous section), or by managing the zones properly yourself. That second option is where a system like HuskHoard, which already sits at exactly the right layer to enforce write ordering, earns its keep.
HuskHoard as a Host-SMR Manager
HuskHoard already lives at the seam described in our piece on how the filesystem presents a false picture of where your data really is: a Rust daemon in user space, watching a directory tree via fanotify, deciding what happens the moment something tries to touch a file. That's not a coincidence of architecture — it turns out to be exactly the position you need to occupy to keep an SMR drive happy, without ever having to speak its native zone protocol.
HuskHoard doesn't issue raw SCSI/SATA zone commands or query hardware zones via libzbd at all. Instead, it treats an SMR drive exactly the way it already treats an LTO tape drive: as a target for large, sequential, append-only containers written through the mounted filesystem. Because it never overwrites in place and never needs to, it naturally keeps SMR firmware happy — drive-managed or host-managed — without HuskHoard having to implement a block-level zone manager at all.
01
A migration policy triggers a write
A tiering or archive policy decides a file should move to the SMR pool — the same mechanism already used to migrate cold files to tape.
02
HuskHoard opens a sequential archive container
Instead of interacting with low-level block commands or hardware zones, the daemon targets the mounted filesystem and opens a new sequential container for the incoming data — effectively a virtual tape file.
03
The Husk Catalog records the exact byte offset
The catalog entry for the stub is extended beyond just a volume UUID — it now also stores the container ID and the exact byte offset the payload begins at. Independent Zstd frames and an internal jump table mean retrieval later knows exactly where to seek without unpacking the whole container.
04
Data streams in as perfectly sequential, append-only writes
Because HuskHoard — not the application — controls exactly when and how migration writes happen, it guarantees every write is a pure sequential append. Streaming large compressed chunks (16MB Zstd frames, typically) and never overwriting in place means there's no random-write path for a naive process to accidentally take, and the SMR firmware never has anything to choke on.
05
Container marked Sealed, next file gets a new container
Once a container reaches its target size — often configured to match a typical hardware zone size, like 256MB — it's sealed. Deleting a stub later doesn't punch holes in a sealed container; reclaim policies decide which sealed containers are stale enough to garbage-collect or rewrite entirely, the same way tiering policies already decide which files are cold enough to migrate.
This sidesteps both failure modes from earlier in one move, without HuskHoard ever having to write a block-level zone manager. Its tape-like, sequential-only write pattern inherently tames even the cheapest drive-managed disks — it never issues a random write, so it never triggers the DM-SMR performance cliff in the first place. And there's no RAID rebuild disaster waiting to happen, because HuskHoard doesn't put SMR drives behind a block-level RAID controller at all; redundancy is handled at the catalog and volume layer, the same layer that already tracks checksums for tape. Replacing a failed drive means re-migrating the files the catalog says were on it — a controlled, sequential operation, not a monolithic resync that saturates every zone on the replacement drive simultaneously.
Informed Choices
The density SMR provides was never in question — the physics behind it has been solid for a decade. What decides whether that density is a bargain or a liability is entirely a question of whether the writes hitting the drive ever break the sequential contract. Leave that to firmware you can't see into on a heavy random-write workload, and you inherit a performance cliff at the worst possible moment. Put a daemon that already treats every archive write as a sequential, append-only stream in charge instead, and the density gain is just — free.
Top comments (0)