Research notes / Magnetic recording

CMR is not refresh-free: adjacent-track interference in HDDs

16 October 2026 / Primary-source review

CMR avoids deliberately overlapping tracks. It does not promise zero internal rewriting. Repeated writes can disturb neighboring stored data, and firmware can read and rewrite that data protectively. A latency spike alone does not identify this mechanism. [1]

Three mechanisms, not one

Write-induced adjacent-track interference (ATI): Repeated activity on a track can degrade nearby recorded data. Protective refresh addresses this accumulated disturbance. Seagate explicitly includes both CMR and SMR. [1, slide 6]
Read-channel inter-track interference (ITI): A reader can receive unwanted signal from a neighboring track. Li and colleagues discuss how track pitch and head offset affect this mixing. This is not itself proof that earlier writes damaged the neighbor. [4, section 2.1]
SMR overwrite handling: Shingled tracks deliberately overlap. Updating previously recorded data must respect that layout, potentially involving other tracks in a band. This constraint differs from counting repeated writes for protective refresh. [5]

Keep these meanings explicit when reading a paper: similar terminology does not make the experiments or mitigations interchangeable. CMR describes a recording layout, not a complete firmware latency contract.

The less obvious cost: accounting granularity

Western Digital's August 2022 technical brief says earlier designs tracked writes at track granularity and refreshed entire tracks. OptiNAND records writes in embedded flash at sector granularity, allowing more targeted refreshes. The same document covers CMR and SMR products. Flash used for this metadata does not turn CMR into a shingled layout. [2, printed p. 2]

That is an architectural claim from the manufacturer, not an independently measured speedup for every workload. The useful distinction is betweenwhere an update may go and how precisely the controller tracks disturbance. Better accounting can reduce unnecessary work; it does not establish that all maintenance disappears.

WD's 2021 engineering interview describes refresh limits varying with density and affected sectors. Its historical examples are not a universal write budget. Do not convert them into a fixed number of safe overwrites for an unidentified drive. [3]

What the evidence actually measures

Mechanism descriptions and research assumptions have different evidential roles. None of these sources provides a general field failure rate for ATI.

Primary evidence and what cannot be inferred from it
Evidence	Supported point	Not established
Seagate, SNIA 2018	Firmware refresh; repeated reuse of a host-managed zone can matter. [1]	A threshold valid for every current drive.
WD, August 2022	Sector-level metadata permits selective refresh. [2]	A workload-independent performance gain.
Li et al., FAST 2017	Local erasure coding studied as an alternative to costly read retry. [4]	Measured ATI refresh frequency in a production fleet.

FAST 2017 is a useful boundary check. Its tail-latency curves are calculated from a model; its ext4 evaluation uses injected sector-read failures on a 500 GB, 7,200 rpm HDD. The FPGA-path performance estimate emulates coding delay rather than measuring a deployed CPU-FPGA system. These results should not be relabeled as observations of write-induced ATI. [4, sections 4.2-4.3]

Local coding also does not promise survival of an entire drive failure. The paper separates that problem from reducing retries. We did not reproduce the experiment or import its numerical gains as predictions for modern HDDs. [4]

A diagnostic boundary, not a diagnosis

Our synthesis: a useful investigation keeps host requests, internal media work and observed completion latency separate. A host-write counter alone does not reconstruct how much data firmware refreshed. A slower request does not reveal whether refresh, read recovery, queueing or another mechanism caused it.

Seagate's host-managed discussion warns that concentrated zone reuse can induce refresh work. That makes spatial reuse worth recording, but it is not a reason to apply a fixed refresh schedule to every HDD. [1]

Retain model, firmware, recording layout, command mix, request size, queue depth and the time window alongside a latency trace.
Record locality and repeated-zone reuse where observable; do not assume logical block numbers expose the physical geometry.
Label an ATI explanation as a hypothesis unless device-specific evidence distinguishes it from alternatives. Do not disable protective maintenance or overwrite valuable data to test that hypothesis.

This checklist is a proposed evidence protocol, not a benchmark we ran. It does not establish a lifetime budget, warranty condition or failure predictor. For the separate accounting question, see HDD annualized workload rates.

Primary sources

Reviewed 16 October 2026. Manufacturer statements retain their product and date scope. No source figures, measured dataset or hardware experiment are presented as Hesela originals.