SMR Secondary Translator: Why a Drive Reports 0 Capacity

This is a firmware failure, not a mechanical one. The drive is not clicking, the heads are fine, & the model & capacity report correctly to the host. What broke is the address map that only SMR drives carry. The sections below cover what that secondary translator does, why its corruption imitates a dead drive, & what a lab does to read the platters underneath it.

What Is the SMR Secondary Translator?

The secondary translator is an indirection table unique to SMR drives. It sits below the normal translator & tracks where each logical block physically lives right now, because a random write lands in a CMR media cache first & migrates into the shingled bands later. A CMR drive has no equivalent layer.

On an SMR drive, two mapping layers work together. Understanding the split is what separates a repairable firmware case from a misdiagnosed dead drive.

Primary translator

Resolves a host logical block address to a physical block, the same role the single translator fills on a CMR drive. On its own it cannot account for data that is still staged in the media cache.

Secondary translator (T2 / MCMT)

The SMR-only indirection table. It records where each logical block currently sits across the CMR media cache & the shingled bands, & the firmware updates it every time garbage collection migrates cached writes into a band.

Each manufacturer stores this layer differently, which is why one family's recovery workflow does not transfer to another. Western Digital DM-SMR drives (Spyglass, Palmer, the EFAX Red family) hold it in Module 190, labeled the T2 translator inside PC-3000. Seagate Rosewood drives keep the Media Cache Management Table in System File 348, working alongside the primary translator in System File 28. Toshiba MQ04 drives build the secondary translator in RAM on every boot instead of storing it in a persistent module, so it is rewritten from scratch each power cycle.

A CMR drive has one translator: a direct logical-to-physical map modified only by dynamic defect reallocation through the P-list & G-list. There is no media cache to drain & no second map to orphan, so the mid-migration power-loss event that zeroes an SMR drive has no equivalent to corrupt on a CMR drive. The mechanical parts are built alike; how CMR and SMR recording differ is a firmware-layer distinction, not a platter one.

Why Does a Corrupted SMR Translator Look Like a Dead Drive Reporting 0 Capacity?

The drive spins up, identifies with its correct model, & reports full capacity, because those values live in a firmware area the corruption never touched. Every User Area sector still returns 0x00, because the logical-to-physical map was orphaned when power dropped mid garbage collection. Standard imaging captures a blank clone.

Power loss during a media-cache flush is the usual trigger. The firmware is partway through migrating cached writes into a shingled band & updating the secondary translator when the rails drop. On the next boot the drive finds a translator that no longer points at valid physical blocks, so it presents an empty address space rather than wrong data. The model string & capacity come from the ROM & adaptive modules, which is why the host sees a healthy-looking drive with nothing on it.

This is distinct from a mechanically dead drive. A failed head stack clicks or beeps, & a seized spindle will not spin at all; neither will identify a clean capacity to the host. An SMR translator failure passes a basic SMART read & sounds normal, which is exactly why customers & general-purpose labs mistake it for accidental deletion or a bad format. The WD SMR translator failure pattern is the textbook version of the all-zeros case.

Why a Write-Blocker Does Not Protect an SMR Drive

A SATA write-blocker stops host writes only. It cannot halt the drive's internal background garbage collection or its media-cache flush, because the drive's own microcontroller runs those processes with no host command involved. Left idle under power, a drive with a corrupted secondary translator keeps overwriting staging data.

The mistake is treating an SMR drive like any other bad-sector case: attach a write-blocker, start a clone, walk away. The blocker suppresses ATA write commands from the operating system, so it does prevent the host from changing anything. It has no visibility into the firmware. Every second the platters spin, the drive can flush cached writes into the shingled bands & rewrite the very translator you are trying to save.

The protection that works is a firmware-level lock. On Western Digital drives that means issuing the Service Area command to lock User Area writing before the power-on sequence completes; on other families it means engaging PC-3000 hardware write protection before the spindle stabilizes. That lock freezes the background firmware processes, not just the host bus, so no imaging tool should touch the host LBA space until it is in place.

How the Lab Recovers a Corrupted SMR Translator

Recovery runs at the firmware layer with PC-3000, not host imaging software. The engineer locks the drive's background processes, saves the secondary translator off the platters, then rolls it back or rebuilds it in workstation RAM. If the translator is beyond repair, Physical Block Access reads the shingled bands directly.

1. Lock the background processes. Connect the drive to PC-3000 & apply the write lock before the power-on sequence finishes, so garbage collection cannot flush the media cache or update the corrupt translator during the session.
2. Save the secondary translator. Read Module 190 out of the Service Area on Western Digital drives using the dedicated T2 module save function, or back up System Files 28 & 348 on Seagate Rosewood drives before any edit.
3. Roll back or rebuild the map. Load an earlier translator state into RAM for logical corruption, or on Seagate patch System File 93 to stop cache migration & reconstruct the Media Cache Management Table in memory, leaving the platters untouched.
4. Fall back to Physical Block Access. When the secondary translator cannot be recovered, switch PC-3000 Data Extractor to read raw shingled bands directly. The output is RAW sector data without file-system structure, but the physical bits are preserved for reassembly.

Imaging happens through PC-3000 or DeepSpar Disk Imager once the translator is stable, never through consumer cloning software that would read the same 0x00 the operating system does. Firmware-level SMR recovery at our Austin, TX lab starts at $900. There is no diagnostic fee, & if we can't recover the data you don't pay. Hard drive data recovery pricing covers CMR firmware cases at a lower tier, since a CMR drive carries no secondary translator to rebuild.