Sources
Generated from the Flash Library ledger for write-of-passage. Do not edit by hand: file new sources with flash-library add-source and claims with flash-library add-claim, then re-export.
Status: primary (the original paper, spec or measurement), secondary (a review or a vendor summary), book-lead (a textbook pointed to it), model (a modeled value), illustrative (a teaching value), own-data (measured here), unverified (no source yet).
| Claim | Value | Status | Source |
|---|---|---|---|
| C-WOP-001 NVMe 1.4: command submission needs at most one MMIO register write; for NVMe over PCIe a command counts as submitted when the host’s write to the Submission Queue Tail Doorbell completes and moves the tail pointer past the slot holding the command. One doorbell write may submit one or more commands. Limit: this is the fast path; whether the host learns of completion by interrupt or polling is the host’s choice. | one MMIO register write (SQ tail doorbell) | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |
| C-WOP-002 Cai et al.: each flash channel connects the controller to its dies over a bus that is typically 8 or 16 bits wide, carrying both data and flash commands. Control pins mark what is on the bus: address latch enable (ALE) for an address, command latch enable (CLE) for a command, rising edges of write enable (WE) and read enable (RE) for each piece of data written or read. Each die on a channel has its own chip enable (CE) signal. The bus broadcasts address, data and commands to every die on the channel, and only the die whose CE is active acts on it. Limit: a description of a typical SSD channel from a survey, not a specific drive; ONFI and Toggle interfaces differ in signal detail. | 8 or 16 bit bus; ALE, CLE, WE, RE; one CE per die | primary | Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives (Proceedings of the IEEE, 2017) https://arxiv.org/abs/1706.08642 |
| C-WOP-003 Cai et al.: NAND cells are programmed by incremental step-pulse programming (ISPP). The controller applies a short high-voltage programming pulse to the wordline, then verifies the cell’s threshold voltage, and repeats pulse then verify until the cell reaches its target. Cells in the wordline are programmed together, and when a cell reaches its target while others have not, ISPP inhibits further pulses to that cell by turning off the SSL transistor of its bitline. Limit: the survey focuses on floating-gate cells (charge-trap cells are analogous, not identical). It gives no pulse count, step size or per-pulse timing, so a caption must not state one. The text names the scheme incremental but does not give the step size, so say rising only as the name implies. | primary | Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives (Proceedings of the IEEE, 2017) https://arxiv.org/abs/1706.08642 | |
| C-WOP-004 Tom’s Hardware review of one 2 TB sample with the Phison E18 controller: the controller is an eight-channel design, and the sample carries thirty-two 512 Gb Micron 176-layer TLC dies, matching the controller’s native chip-enable capability for interleaving. Four dies per channel is the sample’s 32 dies divided by 8 channels, an inference: the review does not say how the dies are spread across channels. Limit: one reviewed sample, not every drive; channel and die counts vary by model and capacity. | 8 channels; 32 dies; 4 dies per channel (inferred) | secondary | Phison PS5018-E18 Controller With Micron 176L TLC Preview: Unleashing the Beast (Tom, 2021-05-25) https://www.tomshardware.com/features/phison-ps5018-e18 |
| C-WOP-007 Clocking one 16 KiB (16,384 byte) page over an 8-bit NAND channel at 1,600 MT/s takes 16,384 B divided by 1.6 GB/s, about 10.2 us (about 4.6 us at 3,600 MT/s). Limit: channel burst only, after the array has already read the page into the data register; spare bytes, command overhead and ECC are not included. The 1,600 MT/s figure is one speed grade (ONFI 4.2) seen in a 2021 review, and a given flash part runs one rung of the ONFI ladder. | 10.2 us at 1,600 MT/s (16,384 B over an 8-bit channel) | model | Write of Passage model arithmetic (the site’s own model) (Eyes on Flash, 2026-10-31) /labs/write-of-passage/ |
| C-WOP-008 Cai et al. describe the LDPC read flow as three stages: hard decoding of the page read with the optimal read voltages, then soft decoding in several levels that each add extra reads at new reference voltages, then superpage-level parity recovery if all of that fails. Figure 30b gives average stage latencies of 80 us per hard-decode iteration, 80 us per soft-decode level and 10 ms for parity recovery. Limit: the figure does not separate the decoder’s own time from the NAND read in each iteration, so no LDPC decoder-only time is given by this source. Figure values are adapted by the authors from industry talks, not a measurement of one drive. | about 80 us per hard-decode iteration; about 80 us per soft-decode level; about 10 ms for superpage parity recovery | primary | Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives (Proceedings of the IEEE, 2017) https://arxiv.org/abs/1706.08642 |
| C-WOP-010 Cai et al.: when the host writes a page of data that already has an older copy, the FTL does not overwrite it. The old copy’s physical location is marked invalid in the block’s metadata and the new data is written to a page in the flash block currently open for writes, with the logical-to-physical map pointing at the new page. Elsewhere the survey explains why: a flash cell must be erased before it is reprogrammed, because programming can only add charge. Limit: general FTL behaviour from a survey, not one vendor’s firmware; erase works on whole blocks, so invalid pages are reclaimed only when their block is erased. | primary | Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives (Proceedings of the IEEE, 2017) https://arxiv.org/abs/1706.08642 | |
| C-WOP-011 Kang et al.: NAND flash does not support in-place update. Once a page is written it must be erased before the same page can be written again, and because reads and writes work on pages while erase works on much larger blocks, an FTL is needed to hide the mismatch. Limit: a 2006 paper about block-level mapping schemes, cited here only for the no in-place update property. | primary | A Superblock-based Flash Translation Layer for NAND Flash Memory (EMSOFT, 2006) | |
| C-WOP-012 Cai et al.: over time page invalidations leave blocks mostly invalid. The FTL periodically performs garbage collection: it picks highly fragmented blocks, migrates any remaining valid pages to a new block, and erases the entire block, which then joins the free list. Blocks with the fewest valid pages are often chosen first. The survey also notes that this remapping adds extra flash writes (write amplification). Limit: general behaviour, not one drive; policy (greedy or otherwise), timing and background scheduling vary by firmware. | primary | Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives (Proceedings of the IEEE, 2017) https://arxiv.org/abs/1706.08642 | |
| C-WOP-013 Zhou et al. (FAST 2021) describe conventional SSD behaviour: the L2P table is persisted on flash and usually cached in DRAM; for every logical page written the FTL also persists the reverse P2L mapping (the logical page number) and a write timestamp as housekeeping metadata on flash, and the latest L2P mappings in DRAM may be lost on sudden power failure. After power-off the FTL scans the persistent metadata in write order and rebuilds the latest L2P table; superblocks carry head and tail metadata for fast recovery, similar to conventional SSDs. Limit: background in a paper about a different design (Remap-SSD); the general mechanism is persisted per-page mapping metadata plus a scan, and the word journal is not what this paper uses for it. | secondary | Remap-SSD: Safely and Efficiently Exploiting SSD Address Remapping to Eliminate Duplicate Writes (USENIX FAST ’21, 2021) | |
| C-WOP-014 US9927985B2 (SK hynix, filed 2016) describes one method of keeping the logical-to-physical (L2P) table recoverable: the up-to-date L2P table lives in volatile memory, an often outdated copy lives in flash, and the controller journals segments of the volatile table to the flash copy as data is written. After a sudden power loss the table in volatile memory is rebuilt from the flash copy, using per-page physical-to-logical data kept in metadata pages and replaying the dirty window of writes not yet journaled. The method estimates rebuild time and triggers more journaling to keep it under a limit. Limit: a patent describing one method, not a finding about all SSDs; journal is the patent’s term for it, and the general mechanism is persisted mapping metadata that is replayed or scanned after power loss (see the Zhou claim). | primary | US9927985B2 - Method of dynamic table journaling (Google Patents, 2016-05-27) https://patents.google.com/patent/US9927985/en | |
| C-WOP-015 NVMe 1.4: a controller reports in the Identify Controller VWC field whether a volatile write cache is present, and the host enables or disables it with the Volatile Write Cache feature (06h, optional). The Flush command asks the controller to make the contents of that cache non-volatile, and it applies to commands already completed before the Flush was submitted. A Write command with the Force Unit Access (FUA) bit set must put its data on non-volatile media before the controller indicates completion; with FUA cleared the bit has no effect. A cache that is guaranteed to reach non-volatile media on power loss counts as non-volatile and the feature does not apply to it. Limit: the spec makes the cache optional and reported by the drive; the claim that many consumer drives complete writes before data is on stable media comes from the Linux kernel documentation (C-FM-186 and C-PLL-045), not from NVMe. | VWC bit; Flush; FUA bit | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |
| C-WOP-016 Cai et al. describe the write data path of an SSD controller: host data goes first to a host FIFO buffer, then to the DRAM manager, which buffers the data in DRAM and tracks where it is; when the controller is ready to write to NAND, the DRAM manager reads the data back from DRAM, the controller encodes it into an ECC codeword, generates a CRC for it and puts both in a NAND flash FIFO buffer, and the data is then dispatched through the flash interface to the NAND. The survey takes the path from a 2011 Micron brief (Rollins), whose figures also show a DRAM attached to the buffer manager between the host FIFO and the NAND FIFO. Limit: one described data path, from a Micron SATA-era brief, not every drive. It varies by drive: DRAM-less drives use other buffers (on-chip SRAM, or host memory buffer), and controllers may acknowledge a write at different points in this path. | secondary | Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives (Proceedings of the IEEE, 2017) https://arxiv.org/abs/1706.08642 | |
| C-WOP-017 Host FIFO, as drawn in the SSD Atlas teaching datapath (nvme-dma block): the first buffer that host write data enters inside the controller, before the DRAM manager. It is a teaching label from the SSD Atlas, not a vendor block of any particular drive. The label follows the Micron 2011 brief (Rollins), which describes data moving from the host transport into a host FIFO and then to the buffer manager, with parity generated on entry and checked on exit. Limit: that brief covers Micron SATA SSDs, so the name and the placement of the block belong to that design. | illustrative | A Comparison of Client and Enterprise SSD Data Path Protection | |
| C-WOP-018 CRC at the NAND FIFO, as drawn in the SSD Atlas teaching datapath (ecc-ldpc block): a CRC is generated on the ECC-encoded data just before it enters the NAND FIFO and checked when it leaves, so corruption in that buffer is caught before the data reaches the flash interface. It is a teaching label from the SSD Atlas, not a vendor block of any particular drive. The Micron 2011 brief (Rollins) states that a CRC is generated just before the data enters the NAND FIFO and checked when exiting, and Cai et al. relay the same path. Limit: Micron SATA SSDs of that era; whether a given modern NVMe controller does this is not public. | illustrative | A Comparison of Client and Enterprise SSD Data Path Protection | |
| C-WOP-019 Samsung 990 PRO carries a DRAM cache of 1 GB LPDDR4 on the 1 TB model and 2 GB LPDDR4 on the 2 TB model, about 1 GB per TB of flash. One drive family; some drives have no DRAM. | 1 GB per TB | primary | Samsung NVMe SSD 990 PRO Data Sheet, Revision 1.0 (Samsung Electronics, unknown) https://download.semiconductor.samsung.com/resources/data-sheet/Samsung_NVMe_SSD_990_PRO_Datasheet_Rev.1.0.pdf |
| C-WOP-021 Phison PS5018-E18 product page: a PCIe Gen4 x4 NVMe 1.4 controller on 12 nm with three Arm Cortex-R5 CPUs, two CoXProcessors and a 4th-generation LDPC engine. One controller family, from a vendor page. | 3 Cortex-R5 + 2 CoXProcessor; 12 nm; 4th-gen LDPC engine | primary | Phison PS5018-E18 product page (PHISON Electronics Corp., 2025-11-18) https://www.phison.com/ps5018-e18/ |
| C-WOP-022 Rule of thumb: a 4-byte mapping entry per 4 KiB page is a ratio of 1 in 1,024, which matches about 1 GB of DRAM per TB of flash. Arithmetic only; the Samsung datasheet gives cache sizes, not the entry size. Controllers can store the map differently. | 4 B per 4 KiB; about 1 GB per TB | model | Write of Passage model arithmetic (the site’s own model) (Eyes on Flash, 2026-10-31) /labs/write-of-passage/ |
| C-WOP-023 Zhou et al. (FAST 2021): with 4 KB pages and 4 byte entries the logical-to-physical table is about 0.1% of SSD capacity, about 1 GB per TB. | about 0.1% of capacity | primary | Remap-SSD: Safely and Efficiently Exploiting SSD Address Remapping to Eliminate Duplicate Writes (USENIX FAST ’21, 2021) |
| C-WOP-025 Frontgrade UT81NDQ512G8T organisation: a page of 16,384 bytes plus 2,208 spare bytes and 2,304 pages per block. One TLC part; pages are 8 to 16 kB in general. | 16 KiB + 2,208 B; 2,304 pages per block | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-026 Linux kernel documentation: many storage devices, especially consumer ones, have volatile write-back caches and signal completion before data reaches non-volatile storage. A flush makes earlier completed writes durable, and a FUA write completes only after its data is committed. | primary | Explicit volatile write back cache control — The Linux Kernel documentation (Linux kernel documentation, unknown) https://docs.kernel.org/block/writeback_cache_control.html | |
| C-WOP-027 Kim and Kim (PLOS ONE 2020) describe a DRAM-less SSD as one that has no DRAM in its controller; it is sold for lower cost, lower power use and a smaller form factor. Their Fig 1 draws the controller as an interface controller, an embedded processor with SRAM, and a flash memory controller, with the DRAM controller and DRAM shown dashed as absent. They state that without controller DRAM the drive cannot use it to cache read data, written data or the address mapping table, so I/O performance is degraded. Limit: the paper says no DRAM in the controller (the drive); it gives no SRAM capacity, and Fig 1 is a generic architecture, not a specific product. | no DRAM in the controller; embedded processor with SRAM shown in Fig 1 (SRAM size not given) | primary | HMB in DRAM-less NVMe SSDs: Their usage and effects on performance (PLOS ONE, 2020) |
| C-WOP-028 DFTL (Gupta, Kim and Urgaonkar, ASPLOS 2009) keeps the complete page-level logical-to-physical map on flash, in dedicated translation pages (assuming 4 B per entry, 512 consecutive mappings fit in one translation page), and holds in the controller’s small SRAM only a Cached Mapping Table of recently used mappings plus a Global Translation Directory that records where each translation page sits on flash (about 4 KB of directory for 1 GB of flash). Limit: a 2009 research FTL evaluated in simulation, not a description of any shipping drive. The paper does not use the term DRAM-less; it assumes a small on-controller SRAM. Its figure of about 0.2% of flash for the stored map comes from 2 KB pages with 4 B entries; do not use it as the 0.1% figure for 4 KB pages (see C-WOP-023). | full map in NAND; cached mappings in SRAM; 4 B per entry; 512 mappings per translation page; directory about 4 KB per 1 GB of flash | primary | DFTL: A Flash Translation Layer Employing Demand-based Selective Caching of Page-level Address Mappings (ASPLOS, 2009) |
| C-WOP-029 Kim and Kim (PLOS ONE 2020) state that page-level address mapping needs about 0.1% of an SSD’s capacity for the mapping table, that controller DRAM is in general not large enough to hold all entries, so only a part of the table is cached and the entire table is kept in NAND flash. Limit: a general background statement the paper cites to other work; it describes the common arrangement, not each drive. | about 0.1% of capacity; part cached, whole table in NAND | primary | HMB in DRAM-less NVMe SSDs: Their usage and effects on performance (PLOS ONE, 2020) |
| C-WOP-030 US9563382B2 (SanDisk, filed 2015) describes a drive whose control tables (FTL metadata) live in its non-volatile memory and are loaded into a small on-device cache that may be SRAM (called L1); the drive can extend that cache into a region of host DRAM reached over the host bus (L2, the host memory buffer); the flash itself is the last level (L3). To find a needed table entry the drive checks the device cache first, then the host cache, and only if it is in neither reads it from non-volatile memory. Limit: one patented design, not a finding about all drives; the patent describes using the host cache for data the drive can lose or rebuild. | L1 device cache (may be SRAM), L2 host memory, L3 NAND | primary | Methods, systems, and computer readable media for providing flexible host memory buffer (2017) |
| C-WOP-031 NVM Express 1.4 defines the Host Memory Buffer as an optional feature (Feature Identifier 0Dh, enabled with a Set Features command) in which the host allocates a portion of host memory for the exclusive use of the controller. In Identify Controller the controller reports a preferred size (HMPRE) and a minimum size (HMMIN), both in 4 KiB units; a non-zero HMPRE means the feature is supported, and an HMMIN of 0 asks the host for any amount up to HMPRE. The host passes a descriptor list of memory regions and sets the Enable Host Memory bit; while it is enabled the host must not write to those regions. How the controller uses the memory is vendor specific. Limit: spec text only; it does not say what any drive does with the memory. | optional; Feature ID 0Dh; HMPRE and HMMIN in 4 KiB units | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |
| C-WOP-032 NVM Express 1.4 section 8.9 says host software may be able to provide none or only a limited amount of the host memory the controller asks for, and that the controller shall function properly without it. The host is to ask the controller to release the memory before a shutdown or a runtime D3 event; once the controller completes that Set Features command the host may reclaim the memory and the controller must not use it. The assigned memory is not persistent in the controller across a reset and the controller does not save HMB settings across power states and resets (the host may hand the same region back with the Memory Return bit set to 1 if the contents are unchanged). The controller shall ensure no data loss or corruption on a surprise removal while HMB is in use. Limit: the spec never uses the word volatile; say not persistent across reset and may be withdrawn, and that the drive must cope. | may be none or partial; controller must work without it; not kept across reset; no data loss on surprise removal | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |
| C-WOP-034 Kim and Kim (PLOS ONE 2020) tested three commercial DRAM-less NVMe SSDs that support HMB (SP A80, HP EX900, Tammuz M730; 3D TLC; 500 to 512 GB) with timing probes and conclude that they mainly use HMB as an address mapping table cache, not as a read cache or write buffer. For SSD-A and SSD-C the read latency stepped up at section counts that scaled with the HMB size, which they take as map caching, and if HMB held only map data the caching unit would be about 4 KB; for SSD-B, whose HMB size could not be varied, the result was not conclusive. The authors say real use is a trade secret, so these are inferences from timing, not vendor statements. Limit: three drives from 2019 on one host (i7-8700, 16 GB DDR4, Ubuntu 16.04.4, fio 2.2.10); other DRAM-less drives may differ. | mapping table cache; not read cache, not write buffer; about 4 KB caching unit; 3 drives | primary | HMB in DRAM-less NVMe SSDs: Their usage and effects on performance (PLOS ONE, 2020) |
| C-WOP-035 In the Kim and Kim (PLOS ONE 2020) tests the host NVMe driver sets the HMB size within a range each drive specifies: SSD-A (SP A80) and SSD-C (Tammuz M730) accepted 8 MB to 480 MB, and SSD-B (HP EX900) accepted only 64 MB. Limit: these are the sizes those three drives allowed in that study, not what an operating system grants by default, and the paper does not report what size a normal desktop grants. | 8 MB to 480 MB (SSD-A and SSD-C); 64 MB only (SSD-B) | primary | HMB in DRAM-less NVMe SSDs: Their usage and effects on performance (PLOS ONE, 2020) |
| C-WOP-037 Kim and Kim (PLOS ONE 2020) report that turning on HMB improved random read performance on the three DRAM-less drives until random read became almost similar to sequential read (heavy workload, all three drives; light workload, SSD-A and SSD-C for both random and sequential read, SSD-B for random read only). With HMB off, SSD-A and SSD-C were much slower than the similar-hardware drive that has DRAM (Kingston A1000) on the light workload. The text states no bandwidth figures; they appear only as bars in Fig 2. Workloads were fio with 4 KB blocks: LIGHT is 1 core, 1 thread and 16 GB of I/O; HEAVY is 12 cores, 72 threads over 100% of each SSD. Limit: three drives, one PC, qualitative result; do not read numbers off the bars. | random read improves with HMB; no bandwidth numbers stated in the text | primary | HMB in DRAM-less NVMe SSDs: Their usage and effects on performance (PLOS ONE, 2020) |
| C-WOP-039 Kim and Kim (PLOS ONE 2020) probed whether three DRAM-less drives use HMB as a write buffer by flooding the drive with writes, then timing a re-write of growing size before and after a flush. SSD-A shows a write buffer: re-write latency is a clean curve below a request size of 964 KB and spreads and rises sharply above it, and the behaviour is the same with HMB off, so the buffer is not in HMB. SSD-B and SSD-C show no clear curve but also no difference with HMB off, so the authors infer HMB is not their write buffer either. The paper says the drives use other media for this and does not name the medium; it notes that the published specification of SSD-C lists an SLC cache. Limit: one probing method on three 2019 drives; the 964 KB figure is one drive; the paper does not say the buffer is SRAM. | write buffer of about 964 KB found on SSD-A and not in HMB; SSD-C spec lists an SLC cache; medium not identified | primary | HMB in DRAM-less NVMe SSDs: Their usage and effects on performance (PLOS ONE, 2020) |
| C-WOP-041 US20180357268A1 (Samsung, filed 2017) describes an FTL for SSDs with low or no DRAM or SRAM. Most metadata, including the logical-to-physical map, block status, program-erase counts, valid counts and read counts, is kept only on NAND (SLC blocks). A host write’s mapping update is not written to NAND at once; it is logged in a small RAM-resident volatile journal (a 16 KB SRAM journal in its example), copied to an SLC journal page on flash when that fills, and committed into the flash-resident L2P pages when the SLC journal pages are full. Reads must check the journals (Bloom filters are used) for a newer mapping. Limit: one patented method; it says what is written to NAND and when, but not how a drive rebuilds its map after a power loss, or what happens to the RAM journal contents if power fails. For the general scan-and-replay idea on drives with DRAM see C-WOP-013 and C-WOP-014, which are background, not equivalent. | map on NAND; updates logged in a small RAM journal (16 KB SRAM in the example), copied to an SLC journal, then committed to flash L2P pages | primary | Data journaling for large solid state storage devices with low DRAM/SRAM (2018) |
| C-WOP-042 DFTL (ASPLOS 2009) notes that although the Global Translation Directory is kept in SRAM, storing it on non-volatile storage aids recovery from power failure (citing another paper). Limit: a single sentence; the paper gives no recovery procedure and does not say what happens to dirty cached mappings on power loss. | GTD on non-volatile storage aids power-failure recovery (one sentence, no procedure) | primary | DFTL: A Flash Translation Layer Employing Demand-based Selective Caching of Page-level Address Mappings (ASPLOS, 2009) |
| C-WOP-043 On a DRAM-less drive, host write data waits in a small buffer inside the controller (on-chip SRAM) or in an SLC cache area of the NAND before it is programmed to the main flash. No saved source states this: the 2020 HMB study shows a write buffer exists on a tested drive and that it is not HMB, and one tested drive’s spec lists an SLC cache, but neither names the medium, and the HMB write buffer in the 2019 HMB-SSD paper is a research proposal. | unverified | no saved source yet (original: needs a source naming the medium; C-WOP-039 and C-WOP-040 are the nearest evidence) | |
| C-WOP-046 Model: one second divided by the rated QD 1 random write of 80,000 IOPS (C-WOP-044) is 1 / 80,000 s = 12.5 microseconds per write as the host sees it. Limits: this is an average at queue depth 1 for one drive family (Samsung 990 PRO, 2022 data sheet), taken from an Up to rating measured with the drive’s write cache active (Intelligent TurboWrite). It is the time until the host is told the write is done, not a time to NAND, and it includes the host software stack and the transfer to the drive. The block size behind the rating is not stated by the data sheet. | 12.5 us per write (1 s / 80,000 IOPS), QD 1 average | model | Write of Passage model arithmetic (the site’s own model) (Eyes on Flash, 2026-10-31) /labs/write-of-passage/ |
| C-WOP-047 Model: one second divided by the rated QD 1 random read of 22,000 IOPS (C-WOP-045) is 1 / 22,000 s = about 45.5 microseconds per read as the host sees it. Limits: an average at queue depth 1 for one drive family (Samsung 990 PRO, 2022 data sheet), from an Up to rating, including the host software stack. It is not the NAND read time (compare tR in the NAND datasheet claims) and the block size behind the rating is not stated by the data sheet. | 45.5 us per read (1 s / 22,000 IOPS), QD 1 average | model | Write of Passage model arithmetic (the site’s own model) (Eyes on Flash, 2026-10-31) /labs/write-of-passage/ |
| C-WOP-048 PCI-SIG FAQ: PCIe 3.0 added 8.0 Gigabits per second per lane per direction of raw bandwidth, PCIe 4.0 added 16.0 and PCIe 5.0 adds 32.0 (earlier generations 2.5 and 5.0). The 3.0 and 4.0 FAQ pages state the same rates as 8.0 GT/s and 16.0 GT/s bit rates. Limits: this is the raw signalling rate before line coding, packet headers and flow control; the FAQ calls it raw bandwidth. The FAQ pages are undated and are PCI-SIG’s own answers, not the base specification text. | 8.0 / 16.0 / 32.0 GT/s per lane per direction (PCIe 3.0 / 4.0 / 5.0) | primary | PCI-SIG FAQ - PCI Express 5.0 (PCI-SIG, unknown) https://pcisig.com/faq?field_category_value%5B%5D=pci_express_5.0 |
| C-WOP-049 PCI-SIG FAQ: PCIe 2.0 at 5.0 GT/s loses 20 percent to 8b/10b encoding, so it delivers 4 Gbps per lane; PCIe 3.0 drops the 8b/10b requirement and uses 128b/130b encoding, so 8.0 GT/s delivers 8 Gbps per lane. Limit: the FAQ page says this for PCIe 3.0 only; the 128b/130b coding for 4.0 and 5.0 is filed separately from a PCI-SIG presentation. Packet overhead is not included in the coding figure. | 128b/130b coding at PCIe 3.0 (8.0 GT/s) | primary | PCI-SIG FAQ - PCI Express 3.0 (PCI-SIG, unknown) https://pcisig.com/faq?field_category_value%5B%5D=pci_express_3.0 |
| C-WOP-050 A PCI-SIG presentation (HOT Interconnects deck on PCIe 6.0) tabulates 3.0 at 8.0 GT/s, 4.0 at 16.0 GT/s and 5.0 at 32.0 GT/s all with 128b/130b encoding, and gives the x16 bandwidth per direction after encoding overhead as 126, 252 and 504 Gb/s (specification years 2010, 2017 and 2019). Limits: a presentation slide table by the standards body, not the base specification text (the specification is members-only and was not read), so it is filed secondary. The slide values are rounded. Packet (TLP and DLLP) overhead is not included. | 128b/130b at 8.0, 16.0 and 32.0 GT/s; x16 after encoding 126 / 252 / 504 Gb/s per direction | secondary | PCI Express®6.0 Specification at 64.0 GT/s with PAM-4 signaling: a Low Latency, High Bandwidth, High Reliability and Cost-Effective Interconnect (PCI-SIG, unknown) https://pcisig.com/sites/default/files/files/HOTI_PCIe6.0.pdf |
| C-WOP-051 Model: usable bandwidth of an x4 link per direction before packet overhead = lane rate x 4 lanes x 128/130 / 8 bits per byte. PCIe 3.0: 8e9 x 4 x 128/130 / 8 = 3.938 GB/s (3.94). PCIe 4.0: 16e9 x 4 x 128/130 / 8 = 7.877 GB/s (7.88). PCIe 5.0: 32e9 x 4 x 128/130 / 8 = 15.754 GB/s (15.75). GB here is decimal (10 to the 9th bytes). Limits: this is the ceiling after line coding only; transaction-layer packet headers, link-layer framing and flow control come on top, so a real transfer gets less. It is a rate, not a latency. | x4 per direction: 3.94 / 7.88 / 15.75 GB/s (PCIe 3.0 / 4.0 / 5.0), before packet overhead | model | Write of Passage model arithmetic (the site’s own model) (Eyes on Flash, 2026-10-31) /labs/write-of-passage/ |
| C-WOP-052 Model: time to move 4,096 bytes over an x4 link at the usable rate before packet overhead = 4,096 B / (lane rate x 4 x 128/130 / 8). PCIe 3.0: 4,096 / 3.938e9 = 1.040 us. PCIe 4.0: 4,096 / 7.877e9 = 0.520 us. PCIe 5.0: 4,096 / 15.754e9 = 0.260 us. Limits: wire time for the payload bytes only. Packet headers (TLP and DLLP) and flow control add to it, and so do the controller, doorbell and completion steps; this is a transfer time, not the latency of a whole write. | 4,096 B over x4: 1.04 / 0.52 / 0.26 us (PCIe 3.0 / 4.0 / 5.0), before packet overhead | model | Write of Passage model arithmetic (the site’s own model) (Eyes on Flash, 2026-10-31) /labs/write-of-passage/ |
| C-WOP-058 Cai et al. (Proceedings of the IEEE, September 2017), section 2.1, state: ‘Data in a block is written at the unit of a page, which is typically between 8 and 16 kB in size in NAND flash memory. All read and write operations are performed at the granularity of a page.’ Limits: a 2017 survey, a typical range not a spec for any one part; the one TLC datasheet saved for this project has a 16 KiB page (C-WOP-025), so a 4 KB host write is smaller than one flash page. | page typically 8 to 16 kB; reads and writes at page granularity | primary | Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives (Proceedings of the IEEE, 2017) https://arxiv.org/abs/1706.08642 |
| C-WOP-059 The 1.9 ms top of Write of Passage’s published TLC program-time range comes from the Frontgrade UT81NDQ512G8T datasheet (2022), a radiation-tolerant part: the datasheet gives a total ionizing dose tolerance guarantee and radiation-environment operating notes. The page labels it an older radiation-tolerant part, not a typical consumer die. | 1,900 us typical tPROG_eff (TLC) | primary | Frontgrade UT81NDQ512G8T: 4Tb TLC NAND Flash datasheet |
| C-WOP-062 Flash-Cosmos lists program latency tPROG of 200 / 500 / 700 μs for SLC / MLC / TLC mode in its simulated SSD built on 48-layer 3D TLC NAND | 200 / 500 / 700 us (SLC / MLC / TLC mode) | primary | Flash-Cosmos:In-Flash Bulk Bitwise Operations Using Inherent Computation Capability of NAND Flash Memory (arXiv, unknown) https://arxiv.org/pdf/2209.05566 |
| C-WOP-063 Flash-Cosmos background text says block erase latency tBERS is much longer (e.g., 3 to 5 ms) than program latency tPROG (e.g., 200 to 700 us), because erase works on a whole block while programming works on a page. Limit: the paper gives 3 to 5 ms as an example in its background section, not as a measurement from its 48-layer chips or a Table 1 entry. Say a few milliseconds, not a precise figure. | about 3 to 5 ms | secondary | Flash-Cosmos:In-Flash Bulk Bitwise Operations Using Inherent Computation Capability of NAND Flash Memory (arXiv, unknown) https://arxiv.org/pdf/2209.05566 |
| C-WOP-064 Frontgrade UT81NDQ512G8T datasheet (2022): effective TLC program page time 1,900 us typical. An older die; current dies differ. | 1,900 us effective TLC program page time (typical) | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-065 US9563382B2 (SanDisk, filed 2015) describes the host reclaiming the host memory it lent the drive, either after telling the drive (which may pull the tables back) or, in another embodiment, without warning, in which case whatever was stored in the host cache is lost. The patent therefore keeps in host memory only data that would not compromise user data integrity if lost or that the drive can reconstruct from its flash, so operation can continue if that data is lost, deleted by the host or unavailable. Limit: one patented design from 2015, not a rule for all drives; the NVMe specification itself describes a host-requested release (see the NVMe host memory buffer claim). | host may reclaim, in one embodiment without warning; host cache holds only data the drive can lose | primary | Methods, systems, and computer readable media for providing flexible host memory buffer (2017) |
| C-WOP-067 Flash-Cosmos (MICRO 2022), section 5.1: the authors characterize 160 real 48-layer 3D TLC NAND chips with a 16 KiB page, and state that under regular SLC-mode programming the chips have a read latency tR of 22.5 us and a program latency tPROG of 200 us. This is the real-chip description and is separate from C-WOP-005, which covers the simulated SSD in Table 1 (tPROG 200 / 500 / 700 us for SLC / MLC / TLC mode; Table 1 repeats tR 22.5 us for SLC mode as a configuration value). Limits: SLC mode only, one research setup on 48-layer chips, no TLC-mode tR for the real chips. | SLC mode on real 48-layer chips: tR 22.5 us, tPROG 200 us | primary | Flash-Cosmos:In-Flash Bulk Bitwise Operations Using Inherent Computation Capability of NAND Flash Memory (arXiv, unknown) https://arxiv.org/pdf/2209.05566 |
| C-WOP-068 NVMe 1.4 Write command (section 6.15): the Number of Logical Blocks (NLB) field says how many logical blocks to write, and it is a 0’s based value, so a field value of 0 means one block. Limit: the logical block size is set per namespace format, so NLB counts blocks, not bytes. | number of logical blocks (0’s based) | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |
| C-WOP-070 NVMe 1.4: a completion queue entry is at least 16 bytes (section 4.6). | 16 B completion | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |
| C-WOP-071 NVMe 1.4: a submission queue entry (a command) is 64 bytes (section 4.2). | 64 B command | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |
| C-WOP-072 DFTL (ASPLOS 2009): the authors report that about 97% of the evictions in the read-dominant TPC-H benchmark did not incur any eviction overheads, because a victim mapping that was not updated is simply dropped. Limit: simulation of a research FTL on one trace. | about 97% of TPC-H evictions needed no extra operation | primary | DFTL: A Flash Translation Layer Employing Demand-based Selective Caching of Page-level Address Mappings (ASPLOS, 2009) |
| C-WOP-073 In DFTL (ASPLOS 2009) a lookup that misses the cached mapping table in SRAM must fetch the needed mapping from its translation page on flash before the data page can be read. If the entry that has to be evicted to make room was not updated, it is simply dropped and the miss costs one translation page read; otherwise the worst case is two translation page reads (victim’s page and requested page) plus one translation page write (the victim’s updated page). Limit: simulation of a research FTL; the paper gives the extra operations, not a measured latency for a real DRAM-less drive. | clean victim: 1 translation page read; worst case: 2 translation page reads and 1 translation page write | primary | DFTL: A Flash Translation Layer Employing Demand-based Selective Caching of Page-level Address Mappings (ASPLOS, 2009) |
| C-WOP-074 A Marvell talk at Flash Memory Summit 2015 (Dorgelo and Chen) reports, for the same 128 GB TLC PCIe Gen3 x1 NVMe drive with a 2-channel DRAM-less controller using HMB, that 4 KB random read at queue depth 32 is 50% lower than a 4-channel DRAM-based SATA drive, 100% higher than a 2-channel DRAM-less SATA drive and 736% higher than a 1-channel DRAM-less eMMC 5.1 drive (CrystalDiskMark, Z97 PC, Windows 8.1). Limit: vendor slide deck, one drive; percentages are as printed on the slides and compare different interfaces. | 4 KB random read QD32: -50% vs 4-channel DRAM SATA, +100% vs DRAM-less SATA, +736% vs eMMC | primary | Host Memory Buffer (HMB) (FMS, 2015) |
| C-WOP-075 A Marvell talk at Flash Memory Summit 2015 (Dorgelo and Chen) reports, for a 128 GB TLC PCIe Gen3 x1 NVMe drive with a 2-channel DRAM-less controller using 128 MB of host DRAM for its look-up table through HMB, measured with CrystalDiskMark on a Z97 PC under Windows 8.1 with the Intel NVMe driver: 4 KB random read at queue depth 1 is 10% higher than a 4-channel DRAM-based SATA drive, 50% higher than a 2-channel DRAM-less SATA drive and 100% higher than a 1-channel DRAM-less eMMC 5.1 drive. Limit: vendor slide deck, one drive (the talk does not name the benchmarked drive’s controller); percentages are as printed on the slides and compare different interfaces; no with-HMB versus without-HMB percentage is printed. | 4 KB random read QD1: +10% vs 4-channel DRAM SATA, +50% vs 2-channel DRAM-less SATA, +100% vs 1-channel DRAM-less eMMC | primary | Host Memory Buffer (HMB) (FMS, 2015) |
| C-WOP-076 ONFI specifications page, release history: ONFI 4.2 (2020) extends NV-DDR3 I/O speeds to 1333, 1466 and 1600 MT/s. Limit: the fastest speeds the release defines, not the speed of any shipping part. | 1,333 / 1,466 / 1,600 MT/s for ONFI 4.2 | primary | ONFI specifications (ONFI, page current 2026) https://onfi.org/specs.html |
| C-WOP-077 ONFI specifications page, release history: ONFI 5.0 (2021) extends NV-DDR3 I/O speeds up to 2400 MT/s and adds NV-LPDDR4, a lower power interface, at speeds up to 2400 MT/s. Limit: the fastest speeds the release defines, not the speed of any shipping part. | 2,400 MT/s for ONFI 5.0 | primary | ONFI specifications (ONFI, page current 2026) https://onfi.org/specs.html |
| C-WOP-078 ONFI specifications page, release history: ONFI 5.1 (2022) extends NV-DDR3 and NV-LPDDR4 I/O speeds up to 3600 MT/s. Limit: the fastest speeds the release defines, not the speed of any shipping part. | 3,600 MT/s for ONFI 5.1 | primary | ONFI specifications (ONFI, page current 2026) https://onfi.org/specs.html |
| C-WOP-079 ONFI specifications page, release history: ONFI 6.0 (2026) drops the older SDR, NV-DDR2 and NV-DDR3 definitions and extends NV-LPDDR4 to 4800 MT/s. Limit: the fastest speed the release defines, not the speed of any shipping part. | 4,800 MT/s for ONFI 6.0 | primary | ONFI specifications (ONFI, page current 2026) https://onfi.org/specs.html |
| C-WOP-080 ONFI specifications page, release history: ONFI 3.2 (2013) scales NV-DDR2 I/O speed to 533 MT/s. Limits: this is the fastest speed the release defines, not the speed of any shipping part (a part runs one rung). The saved page is the ONFI summary page (retrieved 2026-10-05), not the specification PDFs. | 533 MT/s for ONFI 3.2 | primary | ONFI specifications (ONFI, page current 2026) https://onfi.org/specs.html |
| C-WOP-081 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), Table 49 TLC Array Characteristics: ERASE BLOCK operation time (tBERS) 15 ms typical, 30 ms maximum. Limits: one older die, TLC mode, a 2022 datasheet. | tBERS 15 ms typ / 30 ms max | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-082 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), Table 49 TLC Array Characteristics: PROGRAM PAGE effective time per page (tPROG_eff) 1,900 us typical, without VPP; PROGRAM PAGE per command (tPROG) 9,500 us maximum. Limits: one older die, TLC mode, a 2022 datasheet. | tPROG_eff 1,900 us typ; tPROG 9,500 us max | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-083 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), notes to Table 49: read performance numbers are measured with the flag check off (Flag Check trim = 0), and the maximum is the worst tR and tRCBSY time when reading a page with all shared pages programmed. | flag check off; read maximum is the worst case with all shared pages programmed | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-084 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), notes to Table 49: with read-retry options 8 to 15, the tR and tRCBSY maximum may be up to 480 us. | read-retry options 8 to 15: tR max up to 480 us | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-085 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), Table 49 TLC Array Characteristics: READ PAGE operation time without VPP (tR) 88 us typical, 150 us maximum; SNAP READ (tRSNAP) 51 us typical, 100 us maximum. Limits: one older die, TLC mode, a 2022 datasheet; the table gives no separate single-plane row (the features list gives 74 us for that, see the previous claim). | TLC Table 49: tR 88 us typ / 150 us max; tRSNAP 51 us typ / 100 us max | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-086 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), Table 50 SLC Array Characteristics: PROGRAM PAGE operation time (tPROG) 226 us typical, 750 us maximum. Limits: one older TLC die operated in SLC mode, a 2022 datasheet; the tPROG typical (226 us) is a datasheet value to set beside the research-chip value of 200 us. | SLC mode: tPROG 226 us typ / 750 us max | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-087 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), Table 50 SLC Array Characteristics: ERASE BLOCK operation time (tBERS) 15 ms typical, 30 ms maximum. Limits: one older TLC die operated in SLC mode, a 2022 datasheet. | SLC mode: tBERS 15 ms typ / 30 ms max | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-088 Frontgrade UT81NDQ512G8T datasheet (version 1.0.0, 1 November 2022), Table 50 SLC Array Characteristics: READ PAGE operation time (tR) 57 us typical, 60 us maximum; SNAP READ (tRSNAP) 27 us typical, 37 us maximum. Limits: one older TLC die operated in SLC mode, a 2022 datasheet; the SLC read figures are for this part’s SLC mode only. | SLC mode: tR 57 us typ / 60 us max; tRSNAP 27 / 37 us | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-089 Samsung SSD 990 PRO data sheet (Rev 1.0, October 2022): at queue depth 1 with one thread, random write is rated up to 80K IOPS, the same figure for the 1 TB and the 2 TB model. The sheet writes K without defining it; read here as thousands. Limits: the data sheet does not state the block size of the random test (it never says 4 KB), these are Up to ratings from IOmeter on a Ryzen desktop test system under Windows, and footnote 4 says write results were measured with Intelligent TurboWrite active (the drive’s fast write cache), so this is a best-case burst rating on a fresh test system, not sustained or steady-state write speed. One drive family, one 2022 revision. | 80K IOPS random write at QD 1, Thread 1 (1 TB and 2 TB) | primary | Samsung 990 PRO: data sheet (Samsung Semiconductor, unknown) https://download.semiconductor.samsung.com/resources/data-sheet/Samsung_NVMe_SSD_990_PRO_Datasheet_Rev.1.0_10129514072296.pdf |
| C-WOP-090 Samsung SSD 990 PRO data sheet (Rev 1.0, October 2022): at queue depth 1 with one thread, random read is rated up to 22K IOPS, the same figure for the 1 TB and the 2 TB model. The sheet writes K without defining it; read here as thousands. Limits: the data sheet does not state the block size of the random test (it never says 4 KB), these are Up to ratings from IOmeter on a Ryzen desktop test system under Windows, and the sheet gives no read latency. For this drive the QD 1 read rating (22K) is far below the QD 1 write rating (80K) because a write can complete into the drive’s cache while a read must wait for the flash. That reason is an inference from the two ratings, not a statement in the data sheet. One drive family, one 2022 revision. | 22K IOPS random read at QD 1, Thread 1 (1 TB and 2 TB) | primary | Samsung 990 PRO: data sheet (Samsung Semiconductor, unknown) https://download.semiconductor.samsung.com/resources/data-sheet/Samsung_NVMe_SSD_990_PRO_Datasheet_Rev.1.0_10129514072296.pdf |
| C-WOP-091 Frontgrade UT81NDQ512G8T datasheet (4Tb TLC NAND, version 1.0.0, 1 November 2022), features list: SNAP READ operation time without VPP 51 us typical; single-plane READ PAGE operation time 74 us typical without VPP (73 us with VPP); multi-plane READ PAGE operation time 88 us typical without VPP. Limits: typical values for one part, an older die (the datasheet says B17A industrial die source and gives no layer count), in TLC mode; current dies differ. The detailed array table (Table 49) lists only one READ PAGE row with 88 us typical and 150 us maximum, so the 74 us single-plane figure appears in the features list but not as its own table row (see the next claim). The datasheet also adds a busy-to-ready step tRTABSY of 10 us typical. | TLC read: 74 us single-plane, 88 us multi-plane, 51 us snap read (typical, features list) | primary | UT81NDQ512G8T 4Tb TLC NAND Flash datasheet (Frontgrade) |
| C-WOP-092 Kim, Lee and Kim (IEEE Access 2019) propose, as a research prototype on the FEMU emulator, using host memory lent through HMB as the drive’s write buffer: the host’s block layer writes straight into the HMB buffer, the controller later flushes dirty buffers to NAND, and the buffer table and LRU lists live in the HMB space. On MSR Cambridge traces the emulated average I/O latency improved by 59.0% to 86.2% across workloads, depending on the HMB buffer size. Limit: an emulator study and a research proposal, not a shipping design; the paper does not discuss dirty data held in host memory across power loss or withdrawal of the HMB, and the later Kim and Kim study found the commercial drives it tested did not use HMB as a write buffer. | research proposal on an emulator; average latency improved 59.0% to 86.2% across workloads | primary | HMB-SSD: Framework for Efficient Exploiting of the Host Memory Buffer in the NVMe SSD (IEEE Access, 2019) |
| C-WOP-093 NVMe 1.4 Write command (section 6.15): the host names the data by Starting LBA (SLBA), the 64-bit logical block address of the first logical block to write (Command Dwords 10 and 11). There is no file name in the command; a logical block is the smallest addressable unit for Read and Write, and an LBA range is a starting LBA plus a number of logical blocks (definitions in the NVMe glossary). Limit: the logical block size is set per namespace format, so the block count counts blocks, not bytes. | starting LBA (64-bit) | primary | NVM Express Base Specification, Revision 1.4 (NVM Express, Inc., 2019) https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf |