Why a small write can move more data

By How things work · myAudience

myAudience original rendered teaching illustration. Image: illustration, not a documentary photograph. · Operator-authored generated illustration; scientific model reviewed separately.

Why a small write can move more data

A storage system has to keep track of where data lives, not just retain its bits. A host asks to change some logical bytes; a controller maps those addresses to storage locations. The amount sent by the host and the amount written internally need not be equal. We will compare two invented mapping policies under three independent constraints: 400 MiB of mapping memory, 310,000 KiB of total internal writes during a specified interval, and 250,000 KiB of writes reaching a designated hot region in that same interval. These are supplied planning allowances, not product endurance ratings. The word hot means a region receiving more writes in this model, not a measured temperature. Keep logical capacity, memory for the map, host payload and internal write traffic separate. A policy must fit every stated constraint to count as feasible here. Nothing in those totals establishes how long a real drive lasts or whether any particular stored file can be recovered.

Suppose the logical address space is 1 TiB and a deliberately simple flat map uses one four-byte entry for each logical indirection unit. Binary prefixes matter: 1 KiB is 1,024 bytes, 1 MiB is 1,024 KiB, and 1 TiB is 2⁴⁰ bytes. A 4 KiB unit requires 2⁴⁰/2¹² = 2²⁸ entries, so the map occupies 4 × 2²⁸ = 2³⁰ bytes, or 1,024 MiB. A 16 KiB unit needs one quarter as many entries and occupies 256 MiB. The larger-unit map fits the supplied 400 MiB allowance; the smaller-unit map exceeds it by 624 MiB. This calculation covers only the stipulated map. Real controllers may use hierarchical or cached mappings, different entry formats and additional metadata, buffers and error-correction structures. The model therefore explains a trade-off without describing every controller or claiming that a real 1 TiB drive needs these exact memory amounts.

Now specify the write policy before calculating its cost: every request rewrites each entire logical indirection unit that it touches, once. There is no combining of requests, compression or deduplication in this example. With 16 KiB units, a 4 KiB write contained within one unit causes 16 KiB of allocation rewrites. An aligned 64 KiB write covers four complete units and causes 64 KiB. A 64 KiB write beginning 8 KiB past a boundary covers the half-open interval [8,72) KiB relative to that boundary. It touches [0,16), [16,32), [32,48), [48,64) and [64,80): five units, or 80 KiB of rewrites. The endpoint 72 is excluded, but it lies within the fifth unit, so that unit still counts. These are logical mapping units, not a claim that a NAND page or erase block has that size. Internal relocation may also happen; we account for its separately supplied bytes later.

Image: illustration, not a documentary photograph. An invented logical mapping model: an aligned 64 KiB request touches four 16 KiB units; shifting it by 8 KiB touches five, so allocation rewrites rise from 64 to 80 KiB. These are logical mapping units, not NAND pages or erase blocks. Four-byte flat-map entries for 1 TiB take 1,024 MiB at 4 KiB granularity and 256 MiB at 16 KiB granularity. The diagram does not establish drive performance, endurance or remaining life.

The interval contains 10,000 aligned 4 KiB requests and 2,000 aligned 64 KiB requests. Small requests make up 10,000/12,000 = 5/6 of the request count, but carry only 40,000 KiB out of 168,000 KiB of host payload: 5/21 of the bytes. Their allocation rewrites are 160,000 KiB; the large requests contribute 128,000 KiB. Divide the combined 288,000 KiB of allocation rewrites by the combined 168,000 KiB of host payload to obtain 12/7, about 1.714. Averaging the individual ratios four and one by request count gives 3.5, which answers the wrong question. Each large request carries sixteen times as many bytes as each small request. A byte-weighted calculation instead gives (5/21 × 4) + (16/21 × 1) = 12/7. Always check which population supplies the denominator: requests, host bytes and internal bytes are different measurements.

The example also supplies 12,000 KiB of additional garbage-collection writes during the interval. Garbage collection can relocate still-valid data while reclaiming storage; its name does not mean deleting the user's chosen files. Add those bytes once to the allocation ledger: 288,000 + 12,000 = 300,000 KiB. The full modeled internal-to-host write ratio is now 300,000/168,000 = 25/14, about 1.786. Keep this result distinct from the allocation-only ratio 12/7. We assume the supplied relocation amount is additional and remains fixed in the changed case; that is a model input, not a prediction of how a real controller reacts. Before interpreting real counters, establish their units, interval and definition. A host-write counter is not automatically a NAND-write counter, and a product may expose additional vendor-specific information. No elapsed time is supplied here, so these byte totals do not establish throughput, latency, writes per day or remaining life.

A whole-device total can conceal a regional constraint. The stipulated routing sends all small-request rewrites, all additional garbage-collection writes and half of the large-request rewrites to the designated hot region. That gives 160,000 + 12,000 + 64,000 = 236,000 KiB there. The other half of the large-request rewrites gives 64,000 KiB in the cool region. The two regions sum to the same 300,000 KiB total, so the ledger conserves bytes. Total headroom is 310,000 − 300,000 = 10,000 KiB; hot-region headroom is 250,000 − 236,000 = 14,000 KiB. Both limits pass. This artificial routing is not a measurement of wear leveling, per-cell erase counts or temperatures. With allocation rewrites held fixed, at most another 10,000 KiB of extra relocation could be added before the global limit is reached; the larger regional margin does not relax that smaller global margin. Feasibility requires checking the intersection of the limits.

Change just the starting alignment of every large request: each now begins 8 KiB past a 16 KiB boundary. Host payload remains 168,000 KiB, but each large request rewrites five units. Large-request rewrites become 2,000 × 80 = 160,000 KiB. Together with 160,000 KiB from small requests and the unchanged additional 12,000 KiB, total internal writes become 332,000 KiB. The ratio rises to 332,000/168,000 = 83/42, about 1.976. Under the same stipulated routing, the hot region receives 160,000 + 12,000 + 80,000 = 252,000 KiB and the cool region receives 80,000 KiB. Both constraints fail: the global allowance is exceeded by 22,000 KiB and the hot allowance by 2,000 KiB. Spare room elsewhere cannot cancel the hot-region excess. Returning to the original alignment restores the original result under this fixed policy; it is a conditional calculation, not instructions to change firmware or a promise about a particular application.

Would smaller mapping units solve the problem? Under the invented 4 KiB policy, both request sizes and the changed 8 KiB starting offset align to unit boundaries. Allocation rewrites would equal the 168,000 KiB of host payload; including the same supplied relocation bytes gives 180,000 KiB and a ratio of 15/14. That lower write total is attractive, but the map still needs 1,024 MiB, so it fails the independent 400 MiB memory allowance. Under the stated choices, the aligned 16 KiB policy is feasible; the shifted 16 KiB policy fails two write limits, and the 4 KiB policy fails memory. A real design decision needs evidence about mapping structure, workload traces, request combining, counter definitions, reclaim behavior, reliability and the workload conditions behind a product's rating. The appropriate conclusion is conditional: this model identifies why a choice fits these allowances, not a universally best drive. Fewer modeled writes do not certify safe operation, data durability, an endurance warranty or completed practical competence.

Sources and model boundaries: Micron’s September 2023 explanation informs the logical mapping and memory trade-off; NVM Express’s June 2022 overview explains why host and internal-write counters need explicit definitions; Micron’s December 2024 discussion explains workload-dependent endurance ratings. The request counts, write allowances and memory budget above are invented teaching inputs, not measurements or manufacturer ratings. Source pages reviewed 6 October 2026: https://www.micron.com/about/blog/storage/innovations/real-life-workloads-more-efficient-large-ssd-capacities https://nvmexpress.org/resource/features-for-error-reporting-smart-log-pages-failures-and-management-capabilities-in-nvme-architectures/ https://www.micron.com/about/blog/storage/ssd/how-server-ssd-endurance-workload-specifications-are-like-tires

Worked example: An invented storage system has a 1 TiB logical address space and four-byte flat-map entries. Compare 4 KiB and 16 KiB logical indirection units against 400 MiB of mapping RAM. In one interval, 10,000 aligned 4 KiB writes and 2,000 aligned 64 KiB writes occur. Each request rewrites every entire touched unit once. Additional garbage-collection writes are 12,000 KiB. All small rewrites, all additional relocation and half of large rewrites reach the hot region. Check total allowance 310,000 KiB and hot allowance 250,000 KiB under the 16 KiB policy.

Map memory is (2⁴⁰ bytes/unit bytes) × 4 bytes. The 4 KiB policy needs 1,024 MiB; the 16 KiB policy needs 256 MiB. Only 256 MiB fits the 400 MiB allowance.

Host payload is 10,000 × 4 + 2,000 × 64 = 168,000 KiB. Small writes are 5/6 of requests but 40,000/168,000 = 5/21 of host bytes.

For 16 KiB units, small allocation rewrites are 160,000 KiB and large allocation rewrites 128,000 KiB. Their combined allocation-only ratio is 288,000/168,000 = 12/7, not the request-count average 3.5.

Add the separately supplied 12,000 KiB once: total internal writes are 300,000 KiB, ratio 25/14 and global headroom 10,000 KiB.

Hot writes are 160,000 + 12,000 + 64,000 = 236,000 KiB; cool writes are 64,000 KiB. Their sum is 300,000 KiB. Hot headroom is 14,000 KiB.

The aligned 16 KiB policy fits memory and both write allowances under the stated assumptions. The totals do not imply a lifetime, per-cell erase count or measured throughput; no elapsed duration, real controller trace or product rating is specified.

Answer: The 16 KiB map occupies 256 MiB and fits; the 4 KiB map occupies 1,024 MiB and does not. The aligned 16 KiB model has 168,000 KiB host payload, 288,000 KiB allocation rewrites and 300,000 KiB total internal writes. Ratios are 12/7 allocation-only and 25/14 including additional relocation. Hot and cool writes are 236,000 and 64,000 KiB; global and hot headroom are 10,000 and 14,000 KiB. All three stated constraints pass for this conditional choice.

Check your understanding: Keep every count, allowance and routing assumption unchanged, but move each 64 KiB request to an offset of 8 KiB past a 16 KiB boundary. Determine touched units, host payload, allocation and total internal writes, the full write ratio, both region totals and both overruns. Could the 4 KiB alternative be selected merely because it has fewer modeled writes? Explain what each comparison does and does not establish.

Answer: Each shifted large request spans [8,72) KiB and touches five 16 KiB units, rewriting 80 KiB. Host payload stays 168,000 KiB. Large rewrites become 160,000 KiB; combined allocation rewrites become 320,000 KiB and total internal writes including the fixed 12,000 KiB become 332,000 KiB. The full ratio is 83/42. Hot and cool totals are 252,000 and 80,000 KiB, conserving the same 332,000 KiB. Global and hot allowances are exceeded by 22,000 and 2,000 KiB. The 4 KiB policy would give 180,000 KiB total internal writes and ratio 15/14 under its stated geometry, but needs 1,024 MiB of mapping memory and fails the 400 MiB allowance. Lower writes alone cannot establish feasibility. No result supplies a real lifetime, warranty, per-cell wear measurement, safe configuration or observed practical assessment.

Why: Start with the actual half-open request span, rather than rounding payload size without its offset. Count whole touched units, sum byte ledgers and divide by unchanged host bytes. Keep the extra relocation term separate and add it once. Verify hot plus cool equals total, then test each independent allowance. The smaller-unit alternative demonstrates why an apparently improved write metric can still fail another constraint. Real mapping, combining, reclaim and rating evidence would be needed before applying the conditional model to a product.