Computed examples / not SSD measurements

SSD mapping-table footprint: exact byte accounting

Name: SSD mapping-table footprint: exact byte accounting
Creator: Hesela
Published: 2026-10-12
License: https://creativecommons.org/publicdomain/zero/1.0/

Twelve constructed flat-map cases distinguish TB from TiB, mapping granularity from host sectors, and cache address coverage from cached user data.

Download CSV12 cases / 8 columns

JSON and provenance / Evaluator code / Research explanation

Method

C in {10^12, 2^40, 4*2^40} logical bytes; G in {4096,16384} bytes per mapping; E in {4,8} bytes per entry; cache payload B=64*2^20 bytes. Entries=ceil(C/G), full map=entries*E, cached entries=min(floor(B/E),entries), cached address span=min(C,cached entries*G). These are selected assumptions, not measured firmware layouts.

A 64 MiB payload budget at four bytes per mapping holds 16,777,216 entries. At 4 KiB per entry they describe 64 GiB of logical addresses, not 64 GiB of user data in RAM. A repeated small working set and a streaming address sequence can use that cache very differently.

All twelve cases. Cache payload = 64 MiB. MiB = 2^20 bytes; GiB = 2^30 bytes. Display rounding only; downloads contain exact integer bytes.
Logical capacity	Mapping unit, KiB	Entry, B	Full map, MiB	Cached address span, GiB
1 TB	4	4	931.32	64
1 TB	4	8	1862.65	32
1 TB	16	4	232.83	256
1 TB	16	8	465.66	128
1 TiB	4	4	1024.00	64
1 TiB	4	8	2048.00	32
1 TiB	16	4	256.00	256
1 TiB	16	8	512.00	128
4 TiB	4	4	4096.00	64
4 TiB	4	8	8192.00	32
4 TiB	16	4	1024.00	256
4 TiB	16	8	2048.00	128

Reproduce

The standalone module needs Node.js and no packages. Inputs and outputs must be safe integers; capacity, mapping unit and entry size must be positive, and cache budget may be zero. Integer division uses BigInt internally, then rejects outputs beyond the safe-number range. The JSON records generation time, Node version and SHA-256 hashes for code and CSV.

node --input-type=module -e 'import { toCsv } from "./ftl-mapping.mjs"; process.stdout.write(toCsv())'

Limits

All inputs are constructed; no devices, firmware, address traces or HMB allocations were measured.
Entry payload omits tags, replacement state, directories, validity bits, reverse maps, alignment and recovery metadata.
No compression or hierarchical/block/hybrid mapping. Four-byte and eight-byte widths are assumptions, not universal encodings.
Coverage is not hit ratio, RAM recommendation, throughput, latency or power-loss protection.
Mapping-unit size is independent of host sector and NAND page size in this model.
Exact integer arithmetic is deterministic; no statistical confidence interval applies.

Column definitions

capacityBytes: Assumed logical capacity in bytes; decimal TB and binary TiB remain distinct.
mappingUnitBytes: Logical bytes represented by one mapping; not necessarily a host sector or NAND page.
entryBytes: Assumed flat-map entry payload in bytes; excludes cache tags and other metadata.
cacheBytes: Assumed mapping-entry payload budget in bytes; not a measured HMB allocation.
entryCount: Ceiling of logical capacity divided by mapping-unit size.
fullMapBytes: Exact bytes in the flat mapping payload, excluding all ancillary structures.
cachedEntries: Whole entries that fit, capped at the full map entry count.
cachedLogicalBytes: Maximum logical address span represented by those entries, capped at logical capacity; not cached user data.

Sources and license

CC0-1.0 for Hesela's original code and computed rows. Source publications retain their own rights.

Nitin Agrawal, Vijayan Prabhakaran, Ted Wobber, John D. Davis, Mark Manasse and Rina Panigrahy. Design Tradeoffs for SSD Performance. USENIX ATC 2008, pp. 57-70, sections 3.1, 3.4 and 4.

Concepts: FTL, mapping cache and HMB.