Research notes / Magnetic recording

Interlaced recording: two neighbors, different write costs

Published 2026-10-21 / Source review and constructed accounting

An interlaced layout limits which neighboring tracks a write can affect. It does not, by itself, cap the bytes written to preserve them. Where the backup lives and how much data is preserved change the answer.

On this page5 sections

Top and bottom describe overlap, not platter surfaces

Interlaced magnetic recording (IMR) alternates narrower top tracks and wider bottom tracks. Each bottom track lies partly beneath its two neighbors. In the studied layout, a top-track update avoids the corresponding neighbor rewrite; a bottom-track update must preserve affected valid top-track data. Empty neighboring space needs no such preservation. [1, section 1]

The layout is distinct from SMR's directional overlap. HAMR describes heat-assisted recording, not an interchangeable name for IMR. The 2018 paper studies their combination.

A saved copy has its own storage boundary

IMRSim's 2022 preprint preserves affected data in memory. Its authors explicitly leave the performance comparison with disk-backed preservation outside scope. Memory holding a saved copy is not evidence that the copy survives a power failure. [3, section 2.1]

KVIMR instead describes a backup region and ordered stages: preserve the neighbors there, update the target, then restore the saved data. Its merged RMW batches these stages to avoid repeatedly protecting shared neighbors. Synchronization remains part of the design, not removable overhead. [2, section 3.3, Algorithms 1-2]

Our inference: compare the complete preservation path before comparing amplification figures. A count of final track rewrites can omit the backup writes that made those rewrites recoverable.

Count bytes before naming the ratio

Let H be one host payload and Q the affected valid bytes preserved across both neighbors. Our model writes H once and restores Q once. Memory preservation reads Q bytes from disk; disk-backed preservation additionally writes Q to a safe backup region and reads it back.

Memory preservation: Disk writes = H + Q; disk reads = Q
Disk-backed preservation: Disk writes = H + 2Q; disk reads = 2Q
Byte write amplification: Disk-written bytes / H

Six invented transfer plans, not measured tracks. All byte columns use KiB (1,024 bytes). Q is the sum of both affected-valid regions.
Case	H	Q	Disk reads	Disk writes	Byte WAF
No affected valid data	4	0	0	4	1
One 4 KiB neighbor	4	4	4	8	2
Two 4 KiB neighbors	4	8	8	12	3
Same data, disk backup	4	8	16	20	5
Larger preservation units	4	32	64	68	17
Larger host payload	16	8	16	32	2

With H = 4 KiB and two 4 KiB neighbors, memory preservation gives 12 / 4 = 3 write amplification. The disk-backup plan gives 20 / 4 = 5. Including its 16 KiB of reads produces 36 / 4 = 9, but that is atotal-transfer ratio, not write amplification.

The fifth row deliberately prescribes larger preservation regions. Its value 17 is not a claim about actual IMR sector geometry. It demonstrates that a neighbor count alone cannot determine a byte ratio. Conversely, changing the host payload changes the denominator even with unchanged Q.

These successful-transfer examples exclude metadata, retries, buffering cleanup, additional preservation of untouched target bytes and synchronization costs. The backup region causes no further overlap in the model. We neither simulate crashes nor claim that these plans are equally durable. Ratios give neither command counts nor elapsed time.

Download the inputs, results and assumptions, calculation, tests and generator. With the code files together, run node --test imr-accounting.test.mjs, then node build-imr-accounting.mjs. Tests exhaust small integer inputs and reject missing, negative, fractional and unsafe byte counts. No storage device is accessed. Exact constructed cases have no sampling confidence interval.

Three studies, different experimental boundaries

DM-IMR, 2018: an IMR simulator with latency equations derived from DiskSim and MSR Cambridge traces. Its WA metric counts bytes written, not all read/write operations. Its Top-Buffer can itself increase the preservation burden on neighboring bottom tracks. [1, sections 2.2 and 3]
KVIMR, 2021: a 100 GB IMR emulation on a CMR HDD, using 2 MB track units; database WAL and manifest metadata reside on a separate SSD in the evaluation. This is not a standalone physical IMR drive benchmark. [2, section 4.1]
IMRSim, 2022: a Linux device-mapper implementation backed by a CMR disk. Its reported WAF is expressed as a write-count ratio, and write-energy effects are omitted. Those boundaries differ from a byte-accounting model. [3, sections 1 and 3.2]

We reviewed these papers; we did not execute their simulators or reproduce their speedups. Historical statements about unavailable products describe the authors' study dates, not a current market survey. An emulator using a real disk does not become a measurement of an IMR recording head.

Questions worth asking before comparing results

Which bytes enter the numerator? Is the backup volatile or persistent? Are operations full-track or partial-region? Can several updates share one preservation pass? Are mapping metadata and synchronization included? Record space utilization, request sizes and workload ordering as well as the allocation policy. A scalar called WAF cannot answer these questions.

Continue with pooled write accounting, SMR staging costs and RocksDB persistence boundaries.

Primary sources

Reviewed 21 October 2026. Original accounting code and generated examples: CC0. Source papers retain their own rights; no third-party figure or experimental dataset is redistributed.