Flash Foundations, Part 6: The Flash Translation Layer

The operating system believes it is writing to a fixed spot on the drive, but every write goes to a fresh physical page. Firmware keeps a record of where each logical address’s current data actually lives, updates that record on every write and consults it on every read.

Part 5 covered the controller silicon. This part covers the firmware that runs on it, the flash translation layerThe flash translation layer is the firmware that maps host addresses to physical flash locations and hides the rules of erase blocks and wear. (FTL). FTL firmware makes NAND look like a fast, rewritable, reliable block device even though the silicon cannot overwrite data in place. Drives with the same NAND and the same controller can still differ here, in speed, in cost and in what survives a power cut.

The FTL tracks every logical block address (LBA)A logical block address numbers the fixed-size blocks the host sees, starting at zero. The drive decides where each one is physically stored. in its logical-to-physical (L2P) tableThe logical-to-physical table records where each logical block currently lives in flash. Every write changes an entry, and every read looks one up., keeps that table safe through power loss and decides whether it lives in DRAM, in a host memory buffer (HMB) or in NAND. The same firmware spares bad blocks and stages writes in a single-level cell (SLC)SLC mode, or pseudo-SLC, runs a multi-level block as one bit per cell. It writes faster and survives more cycles, but holds a fraction of the data. cache, and each of these mechanisms looks different to the host when it fails.

The mapping problem: why indirection had to exist

Hosts address storage as a linear array of LBAs. LBA 0 comes first, then LBA 1, LBA 2, and so on to the end of the drive. A host expects to write LBA 1000, read it back, overwrite it and read it back again. NAND cannot do that. A programmed page cannot be overwritten in place, and changing it means erasing the whole block that holds it. Part 3 covers why the erase unit is a block. Erasing a block on every overwrite would make writes slow and would burn through the program/erase (P/E) cycleA program/erase cycle is one write of a block followed by its erase. Each cycle wears the oxide, and the cell type sets how many cycles it tolerates. budget.

Indirection solves this. A write to LBA 1000 does not make the FTL write to a fixed physical place called LBA 1000. It programs the data into a free page, points the table entry for LBA 1000 at that page and marks the page that held the old data invalid. That page waits for garbage collectionGarbage collection copies the valid pages out of mostly stale blocks and erases those blocks, so there is always free space for new writes. (GC) to reclaim its block. From the host’s side LBA 1000 was overwritten, while the NAND wrote somewhere else.

Figure 6.1 follows one overwrite in four steps. The old page stays in its block, marked invalid, until GC reclaims the whole block, which Part 7 covers. Erasing is deferred and batched, so one erase pays for many overwrites.

This works because of the L2P mapping table, a record of which physical page holds the current version of each logical address. Every read looks it up and every write changes it. If the table is lost or wrong, no read can find the data it should return.

Superblocks and parallelism: how the FTL exploits the hardware

A single physical block sits in one plane of one die. Writing it one page at a time gives single-die, single-plane throughput, far below what a finished SSD delivers. The Flash-Cosmos model of 48-layer TLC NAND programs a 16KiB page in 700µs, so one plane writes about 23MB/s, while Samsung rates its 990 PRO 2TB at up to 6,900MB/s sequential write. Part 3 covers planes and dies, and Part 5 covers the channels that connect them.

A superblock is the firmware unit that groups blocks across planes, dies and channels into one logical erase unit. Allison and colleagues give a small example. An SSD with 8 dies, 2 planes per die and 2 erase blocks per plane has a superblock of 32 erase blocks. Firmware stripes writes across all of them and erases all of them together, so their program and erase times overlap instead of adding up. In a design that reclaims whole superblocksA superblock groups one block from each die or plane so the controller can write and erase them together as a single larger unit., GC also frees them as units, which is why the makeup of the unit matters.

Figure 6.2 draws that example, eight dies with two planes each and two erase blocks per plane. Every highlighted cell is one block of the same superblock, so a write fans out to all of them at once. Throughput rises toward the number of blocks written in parallel, until the channel buses or the controller become the limit.

Firmware tracks which blocks belong to which superblock and handles the edge cases. These include partial superblocks at capacity boundaries and the fact that a retired block cannot join a superblock (see bad block management below). How blocks are grouped, how writes are striped and how partial fill is handled all affect sustained throughput and the write amplification factorWrite amplification factor is the data written to NAND divided by the data the host wrote. A value of 1 means no extra internal writes. (WAF).

A sequential workload tends to invalidate whole superblocks together, which leaves GC little to copy. A random workload scatters invalid pages across many superblocks, so GC must copy the valid remainder of each one before it can erase it. That scatter is the source of elevated WAF under random load, and Part 7 defines what the copies cost.

Where the map lives: DRAM, HMB, and the cost of a lookup

Take a 1TB drive mapped in 4KB units. 1TB / 4KB = about 244 million entries. At 4 bytes per entry, that is about 0.98GB of table. Zhou and colleagues at FAST 2021 put the table at about 0.1% of capacity. Larger drives need proportionally more. A drive keeps this map in one of three places, and where it lives sets how fast every read and write can be served.

Figure 6.3 orders the three by lookup cost. Dedicated DRAM is fastest and most predictable. Host memory through the Host Memory Buffer (HMB)Host memory buffer lets a DRAMless NVMe drive borrow a small region of host RAM to cache part of its map. trades a DRAM die for a trip across the PCIe link. With neither, each cache miss costs a NAND read. The panels are qualitative, since the cost of a hit or a miss depends on the controller and the workload.

DRAM-backed mapping

DRAM-backed mappingThe map can live in on-drive DRAM, in a slice of host memory, or mostly in flash with a small cache on a DRAMless drive. Placement sets random-read speed. keeps the L2P table, or most of it, in dedicated on-drive DRAM. Samsung’s 990 PRO datasheet lists 1GB of LPDDR4 on the 1TB model and 2GB on the 2TB model, and the ZNS paper puts page-level mappings at about 1GB per 1TB. A lookup in the cached table is a direct memory read. Some designs load the map in segments as the host touches each region, so the first access after power-up can cost an extra NAND read even with DRAM present. High-performance consumer drives and most enterprise SSDs use dedicated DRAM. Its cost is the DRAM die, its board routing and its rails. An LPDDR4 package asks for three supplies, VDD1 near 1.8V and VDD2 and VDDQ near 1.1V, with VDDQ at 0.6V for LPDDR4X. Without the package a drive drops those rails too.

Host memory buffer (HMB)

Host Memory Buffer (HMB) uses a portion of the host’s RAM as a map cache. The NVMe base specification makes it an optional feature. The controller requests memory during initialization, the host may grant none or less than requested, and the controller must still work without it. HMB removes the DRAM die from the PCB, but a lookup now crosses the PCIe link and shares host memory with everything else. Under random I/O it can stall behind host memory contention or PCIe arbitration. Sequential workloads and random reads over a small LBA range may show no difference from on-drive DRAM. Random reads across the full drive and sustained random writes at high queue depth often expose the gap. The DRAM-less SSD myth page works out how much of the map a small buffer covers.

DRAMless designs without HMB

DRAMless designs without HMB carry no DRAM of their own and borrow none. The full L2P table lives on NAND, and only hot portions are cached in the controller’s small on-chip static RAM (SRAM). The DFTL paper (Gupta, Kim and Urgaonkar, ASPLOS 2009) describes this demand-based caching. It notes that a page-level mapping table for 16GB of flash needs about 32MB of SRAM, so it keeps only part of the table cached. The paper’s example flash has 2KB pages, half the 4KB unit used above, so its table is about twice as large per gigabyte. HMB drives are DRAMless too, but they keep a map cache in host memory. Once the working set outgrows the cache, every miss costs a NAND read, and changed map pages must be written back, which adds writes to NAND that the host never asked for. These drives work for sequential workloads and light consumer use but degrade under sustained random I/O, so they suit cost-sensitive embedded and edge designs better than performance-sensitive deployments.

Product specifications show whether a drive has dedicated DRAM. A nonzero HMPRE (Host Memory Buffer Preferred Size) field in the Identify Controller data shows HMB support. It says nothing about DRAM, since a DRAMless drive without HMB returns zero as well. Random read latency under sustained mixed workloads matters most in practice. One reasonable recipe is a mixed-workload test at 4K random, queue depth 1 and 32, at a 70/30 read/write mix over 30 minutes, run across the full LBA range after preconditioning. Those values are only a starting point, because no standard sets them. Together they show whether the mapping architecture holds up under pressure.

Power loss protection: hardening the map against the worst case

If the L2P table is lost or left inconsistent, the drive cannot reliably find user data. A power loss at the wrong moment, mid-write, mid-update or mid-journal-flush, can leave the table half updated. New mappings exist only in DRAM, and the mappings on NAND no longer match the data. Power loss protection (PLP)Power loss protection uses stored energy to let a drive finish writing buffered data and metadata when power fails, so acknowledged writes survive. is the hardware and firmware that closes that gap.

Samsung’s white paper says its enterprise SSDs carry full PLP built on tantalum capacitors, and that client SSDs normally omit it because capacitors cost money in a price-sensitive market. PLP costs a bank of capacitors sized to flush the write buffer and dirty metadata, the board space that bank requires and the validation burden of proving the circuit works across temperature and aging. An enterprise price absorbs those costs, and consumer margins often cannot.

Figure 6.4 compares two published hold-up times, the window a design has to hit. As power drops the controller detects the loss and runs on stored energy, and everything the host was told is safe must reach NAND before that energy is gone. Four mechanisms work together to make that flush correct.

Capacitor-backed flush

After an unexpected power loss, the capacitorHold-up capacitors store enough energy to finish in-flight writes and save metadata after the host power fails. keeps the controller running long enough to finish pending writes, including map updates and journal entries. That hold-up time is short. Phison quotes a maximum of 25ms for its design.

Mapping journal

Firmware keeps a write-ahead journal of mapping changes, separate from the main table on NAND. Every L2P update is logged, and with PLP the capacitor guarantees the journal reaches NAND before power runs out.

Atomic operations

Critical metadata updates either complete fully or revert completely, so the map has no torn writes.

Checksum validation

Every journal entry carries a checksum. On recovery the firmware validates each entry before applying it, and it discards a corrupted entry and everything after it, which rolls the map back to the last verified state.

Hold-up hardware varies by market. Intel’s DC S3700 used two 35V, 47µF radial electrolytic capacitors, bent into a cutout in the board. Intel’s drive also carried sensor logic that periodically checked capacitor health. Qorvo’s enterprise SSD guide likewise lists storage-capacitor health checks among its PLP functions. A bank is not wired straight to the rail. A boost regulator charges it to 25 to 35V, depending on the maker, and the power management IC (PMIC) switches to the bank when input power fails. Many consumer drives carry no bank, and The SSD Review’s Crucial MX500 review describes that drive’s power loss immunity as coming from the NAND and firmware instead of capacitors.

Designers size the capacitor to flush the volatile write buffer and pending metadata at the controller’s peak NAND write rate, in the worst case where the buffer is full of acknowledged data. Enterprise drives with larger DRAM buffers and higher sustained throughput need larger banks. Firmware tests capacitor health at power-on and at intervals. A depleted or failed capacitor sets a flag in the Self-Monitoring, Analysis and Reporting Technology (SMART)The SMART and NVMe health log reports counters such as temperature, percentage used, available spare, media errors and data units written. Critical Warning bitmap, separate from the temperature, spare capacity and reliability warnings.

Hold-up energy protects more than the write buffer, because a cut program can damage data that was already complete. A 2011 measurement study by Tseng, Grupp and Swanson cut power to raw chips mid-program. The chips had feature sizes from 72nm to 34nm, and the planar multi-level cell (MLC) chips stored 2 bits per cell. A cut during the upper-page program could corrupt the lower page of the same cells, completed earlier. Part 3 explains the page types. The paper calls them first and second pages. Lower-page bit error rate reached 25% on one chip and 50% on another, and the datasheets did not mention the effect. Nor were the two pages of a pair neighbors. In most cases on the studied chips the first page at address n paired with the second page at n+6, so firmware that treats only the last page written as at risk misses its pair. Pages whose program was cut short but still read back clean were also fragile under reads. One began showing read-disturb errors after about 1,000 reads, where a fully programmed page took 2.8 million. These 2011 results come from planar MLC chips, so they show a mechanism and give no rate for a current drive.

Each of the three mitigations the authors list has a limit. Programming each pair as one unit is hard because the pair is not consecutive. Keeping map metadata only in upper pages leaves user data exposed, and it trades against Part 3’s advice to keep critical metadata on lower pages or in SLC mode. A data coding that avoids the damaging cell transition worked on one chip and failed on another. Micron’s 2014 white paper on unexpected power loss describes a hardware answer. Its M500 client drive used a small ceramic bank that held up for about 1ms, by Micron’s own account. That was enough to return an in-progress lower page to its original level before the upper-page program started, so it protected data at rest and left acknowledged writes still in the buffer exposed. Its enterprise drives used larger tantalum banks that also finished in-flight writes and saved the map.

Hosts ask for durability with two commands. Force Unit Access (FUA)Force Unit Access makes one write reach stable media before completing. Flush makes all earlier writes stable, and both give the host a durability guarantee. makes one write reach stable media before it completes, and Flush makes every earlier write stable. A drive that acknowledges either one while the data sits in volatile buffers breaks that promise. PLP can let a drive keep that promise with those buffers in play. The kernel documentation describes how the host uses both.

Drives also report an atomic write guarantee. AWUNAWUN and AWUPF report the largest write the drive guarantees to complete entirely or not at all, for normal operation and after power failure. (Atomic Write Unit Normal) is the largest write the drive guarantees to commit whole or not at all in normal operation. AWUPF (Atomic Write Unit Power Fail) is the same guarantee across a power failure. Both fields are zero-based. A value of 0 means one logical block, 512B or 4KB depending on the active format, so every compliant drive guarantees sector-level atomicity. Any database whose write-ahead log needs larger atomic writes checks that AWUPF is at least its I/O unit. Some enterprise drives with strong PLP report a larger value. Both fields are in the Identify Controller data and are real procurement criteria.

Without PLPWithout power loss protection, a sudden power cut can lose data held in volatile buffers and can leave the map out of step with the flash., consumer drives rely on the file system journal to keep file system metadata consistent after an ungraceful shutdown. The drive’s own map has no guaranteed flush, and FTL recovery describes what the firmware can rebuild from that state. To see what a power cut does to acknowledged writes, with and without capacitors, open the Power Loss Lab. Its model is illustrative and carries no vendor data. The power-cut myth page covers what a cut does to whole drives in a lab test.

FTL recovery: what happens when power returns

Recovery runs at power-up after an ungraceful shutdown, with or without PLP, before the drive reports ready. Either way the firmware finds the last known-good state, verifies it, applies any recoverable pending work and then reports ready. With PLP it has the flushed journal. Without PLP it has only what reached NAND.

Figure 6.5 splits recovery into three outcomes. A flushed journal restores the map exactly. Without one, the firmware rebuilds the mapAfter a power loss the FTL rebuilds its map from the last checkpoint by replaying a journal of later changes, or by scanning the flash. from physical evidence. When that evidence is unreadable, addresses are lost.

With PLP: journal replay

The capacitor gave the controller enough energy to complete in-flight writes and flush the journal. On power-on, the firmware locates the journal, validates each entry against its checksum and replays the sequence to restore the in-memory map to its exact pre-shutdown state. Because the capacitor’s energy budget bounds the journal, replay is short, and the drive comes up consistent with no acknowledged write lost.

Without PLP: scan recovery

Without PLP, the journal’s newest entries can still be in DRAM when power dies, so the firmware cannot rely on it. Recovery starts from the most recent complete map checkpoint on NAND. From there, the firmware reads the out-of-band (OOB) spare-area fields of the regions written afterward. Valid OOB markers and consistent error-correcting code (ECC) checks mark a completed write. Pages that were mid-program when power died have missing OOB data or more ECC errors than a fresh page should show. The firmware discards them and rebuilds the table up to the last completed operation. Any write that was acknowledged but not yet committed to NAND is lost.

Where recovery fails

This sequence assumes the journal and OOB fields are readable. A block that was mid-erase when power died is in an indeterminate state. Its cells are partly erased, their threshold voltages are undefined and ECC cannot validate the contents. Firmware retires that block. In the same 2011 study, cutting an erase short raised the error rate of the next program to that block from zero to 0.4 to 0.9% on most chips tested, even though the erase had looked finished. That supports retiring the block and says nothing about rates on current NAND. If that erase was part of relocating a map structure, the firmware falls back to the structure’s previous copy. If the old location was already marked invalid, the affected logical addresses lose their physical backing.

Scan time scales with how much data was written between the last checkpoint and the power loss. A drive that checkpoints often recovers quickly, and one that checkpoints rarely can run a long scan at the next boot, which shows up as a slow start. Often the operating system detects the dirty shutdown, runs file system recovery, and the drive then operates normally, though nothing guarantees that outcome.

SLC folding: the write the host never sees

Most consumer drives built on triple-level cell (TLC) and quad-level cell (QLC) NAND first land incoming writes in an SLC cache, also called pSLC (pseudo-SLC), a region of NAND run in SLC mode, storing one bit per cell, so the write programs fast and the host gets its acknowledgment quickly, though the data has not finished moving. At some point the controller must relocate whatever is still valid to its permanent TLC or QLC location in the main array. That relocation is folding. Many controllers run it through the same relocation engine as GC, but it serves a different purpose. Hosts never see it, and only sustained-write tests that exhaust the cache expose it.

In one patented design, SanDisk’s fold reads the SLC source pages, three per TLC wordline, applies the full multi-level programming sequence to the destination wordline, and invalidates the SLC sources. The SLC write was fast because one bit per cell leaves wide voltage margins. A TLC write is slower because the cell divides its voltage range into eight states and has a narrower margin between them, and it needs many more program-verify pulses, even when current 3D TLC programs all three pages of a wordline in one pass. TLC programming speed therefore constrains the fold rate. Part 3 covers the timing parameters. The Flash-Cosmos model of 48-layer TLC NAND lists tPROG at 200µs in SLC mode and 700µs in TLC mode.

Figure 6.6 shows the sequence for one wordline. Every byte that lands in the SLC cache and is still valid at fold time costs two writes to NAND, as Micron’s patent background puts it. One is the SLC write that acknowledges the command and the other is the fold write that moves the data to its permanent TLC location. Under ideal conditions, with spaced-out host writes that give the controller ample idle time to fold, this overhead does not show up in throughput. It still costs endurance. Both writes count in write amplification. Part 7 defines WAF over all NAND writes and tracks the fold copy separately from GC.

Under sustained writes, incoming data can fill the SLC region faster than the fold scheduler can drain it. The controller then folds and accepts new writes at once, and the two compete for NAND bus time. Once the region is full, the controller either writes new data straight to TLC or holds it until a fold frees space. Part 9 describes that cache exhaustion from the host’s throughput side. Here it is the fold scheduler running out of room.

FoldingFolding rewrites data held in SLC blocks into TLC or QLC blocks, which frees the SLC space but costs extra writes inside the drive. is designed to be safe against power loss. In a design that keeps the SLC source, an SLC page stays valid until the TLC destination write completes and its OOB fields check out. If power is lost mid-fold, the TLC page may be partly programmed or absent, but the SLC source is intact. On recovery the firmware detects the incomplete fold, invalidates the partial TLC write and schedules a new fold from the SLC copy. The design intent is that no data is lost, with or without PLP, which makes folding one case where a drive without PLP can recover cleanly instead of rolling back to a map checkpoint.

Right after a write burst, a drive can show background NAND writes while the host is idle or reading. That is usually the fold scheduler draining the SLC cache. Folding is a second write of data the host already wrote. It lands in the SLC cache first and is written again to TLC later, and the cache is cleared as that data migrates. Writes to NAND that continue for days with a read-heavy host are not folding. Part 7 covers the refresh that causes them. A drive that writes about twice as much to NAND as the host sends while the host keeps writing steadily is folding everything it stages. Folding adds one extra NAND write per staged byte, and GC and refresh add the rest of the total WAF. The standard NVMe health log counts only host writes, so counts of writes to NAND need a vendor or Open Compute Project (OCP) log.

The blocks that never appear: bad block management

Even new NAND can contain bad blocks from the manufacturer, in different numbers and places on each device. Manufacturers pre-mark them, and an NXP application note on planar-era parts puts the factory marker at a fixed offset in the first page of the block, which is one convention from that era. Firmware must route around those blocks before it programs a single user byte.

Firmware keeps a Bad Block Table (BBT)Blocks that fail at the factory or in use are recorded in a bad block table and replaced from spare blocks, so the drive keeps its capacity., a persistent record of every block the controller will not use. It starts from the factory defect list, loaded and verified at initialization, and grows through the drive’s life. A block that fails a program or erase, or shows read error counts beyond the retirement threshold, is added to the BBT and retired. The L2P table never points to a block in the BBT. To the host, bad blocks simply do not exist. They are absorbed into capacity the drive never advertises.

Manufacturers provision raw NAND above the advertised capacity. In Seagate’s table, a drive marketed with 7% overprovisioning has 15% true physical overprovisioning, because a gibibyte is about 7% larger than a gigabyte, which leaves user capacity at about 87% of the raw flash. At 28% marketed the table gives 37% true overprovisioning and user capacity falls to about 73%. Figure 6.7 splits the raw flash of both drives. The table does not show how the reserved slice divides among its uses. One documented use is parity. In Luo’s 2018 CMU thesis, the parity bits of superpage-level parity are stored in part of the overprovisioned space, which leaves less usable overprovisioning. Overprovisioning and its effect on performance and on the terabytes-written (TBW)Terabytes written is the total host data a manufacturer rates a drive to absorb over its life under the warranty conditions. rating are in Part 9.

As the BBT grows, effective overprovisioning shrinks. GC has fewer free blocks to work with, WAF rises, and endurance falls off nonlinearly toward the end of the drive’s life. Part 7 covers the retirement rate. Heavy use well outside the rated workload can retire blocks faster than the spare area was sized to absorb. Available Spare in the SMART / Health Information log tracks this shrinkage, and the controller warns when it drops below the Available Spare Threshold. That warning is the BBT growth signal reaching the host, expressed as a percentage rather than a block count.

Lifetime hints: how streams and FDP keep short-lived data apart

An FTL groups incoming writes into physical blocks without knowing whether different writes will become invalid together or far apart. Short-lived data, such as a write-ahead log entry or a temporary cache block, and long-lived data, such as a database table file or a configuration record, often share a block. GC then cannot reclaim that block without first copying out the long-lived data, even after its short-lived neighbors are stale. Mixing lifetimes in one erase unit is a primary structural source of write amplification, and no GC algorithm can undo it without information about data longevity.

The NVMe Streams Directive targets that mixing. Flexible Data Placement (FDP) succeeds it and does the same job with placement handles instead of stream IDs. In either one the host tags each write with its expected lifetime, and the FTL uses the tags to co-locate writes with similar lifetimes in the same physical blocks.

Figure 6.8 shows the effect on one reclaim. When a block holds only short-lived data, every page goes stale together, so GC erases it with no valid data to move. Write amplification from mixed-lifetime blocks largely disappears for the data that is tagged accurately.

The gain can be large in workloads that benefit. Kang and colleagues built the original multi-streamMulti-stream lets the host tag writes with a stream number so data with similar lifetimes lands in the same blocks. prototype and report that it improved the worst-case update throughput of a Cassandra database by nearly 56%. Allison and colleagues report an ideal device write amplification near 1 for a flash cache on FDP, on production traces from Meta and Twitter, and CacheLib’s documentation gives 1.03 with FDP against 1.22 and 3.22 without it in its example runs at 50% and 100% device use. A drive needs firmware that supports the directive. The OACS (Optional Admin Command Support) field reports Directives in general, and a Directive Receive Identify command confirms Streams specifically. A host needs an application or storage stack that issues tagged writes with accurate lifetime classes. Both are required, and a drive that supports hints but receives untagged writes gains nothing. Confirm support with those two checks during qualification for write-intensive deployments, where lower WAF directly extends service life. Part 10 compares FDP with Zoned Namespaces.

NVMe sanitize: intentionally destroying the FTL state

Every mechanism above maintains the FTL’s integrity. SanitizeNVMe sanitize offers block erase, overwrite and cryptographic erase, and a drive may support any of them. Each runs in the background and survives a power cycle. is the deliberate inverse. It is an NVMe command that destroys all user data in every location able to hold it, including caches and unallocated or deallocated areas of the media, and resets the map to a known-empty condition.

Figure 6.9 sorts the three variants by what the drive reports, and each costs something different. A fleet that sanitizes drives between tenants pays that cost on every cycle, so the choice matters at scale.

The table gives the three variants NVMe defines, with wear cost the biggest difference.

Crypto Erase is the right choice on a drive that reports it, being fast and, by default, endurance-neutral. All data stays physically on the NAND, but it is unrecoverable without the destroyed key. Many drives that report it are self-encrypting drives (SEDs), but the capability bit is what the command checks, and Part 5 covers how those drives encrypt. Block Erase is the fallback for drives without it, and it leaves the media physically clean and ready for a new tenant. A fleet that sanitizes drives between every tenant assignment consumes about one P/E cycle per sanitize event. That cost lands on the NAND’s P/E budget, shows up as SMART Percentage Used, and matters only when sanitize frequency is high. Part 9 covers the endurance budget.

Sanitize status is reported through the NVMe Sanitize Status log page. While a sanitize runs, the drive rejects every I/O command (current revisions of the spec make Flush the one exception) and every admin command not on a short permitted list, with a Sanitize In Progress status until it completes.

NVMe 1.4c states that sanitize operations do not affect the Replay Protected Memory Block (RPMB) or boot partitions, so neither is cleared by the commands above. RPMB is an optional authenticated store that sits outside every namespace. The host programs a 32-byte key once, and the controller never lets it be read back. Each access carries a message authentication code, a hash-based message authentication code (HMAC) built on the SHA-256 hash. It covers the frame’s data, random nonce, write counter and other fields, but not the padding or the code itself. A counter tracks successful writes and cannot be reset, so a recorded write replayed later fails because the counter has moved on. Each RPMB target holds 128KiB to 32MiB, and it is reached with Security Send and Security Receive instead of ordinary reads and writes.

To watch a secret survive delete, format and overwrite, then die to a real purge, open the Secure Erase Lab. Its model is illustrative and carries no vendor data. The secure erase myth page covers what a block erase gives back to a used drive and what it cannot.

In the field: reading an FTL failure from the host

An FTL does not report its own failures as FTL failuresFTL failures show up to the host as a drive that becomes read-only, reports the wrong capacity, stalls, or returns old or empty data.. Hosts see a command status, a counter that moved or data that is wrong, and the job is to work back from that to the mechanism. NAND wear, interface errors and firmware faults produce the same status codes, so one reading is never enough. Status code, wear counters and shutdown history have to agree before you blame the map.

Incomplete flush without PLP

A drive that loses power mid-write recovers by scan, as above. Writes that never reached NAND are absent. The file system detects the dirty shutdown and begins recovery, and the lost data is the unflushed data only, with the drive itself undamaged.

Mapping table corruption

A fault, such as sustained overvoltage, a firmware bug or a bad block that holds critical metadata, corrupts the L2P table beyond what journal replay can fix. Validation lets the controller detect inconsistencies and must choose between serving possibly stale dataStale data is an older copy of a block returned after power loss because the map update never reached flash. and refusing to operate. Well-built firmware puts the drive in a read-only or degraded state and fails writes. Poorly built firmware may rebuild the table and produce entries that point at the wrong physical pages.

Silent stale data return

This form is the most serious. The drive returns data without signaling any error, but the data is a previous version of the logical address. From the NVMe host the command completed with success status. There is no media error and no cyclic redundancy check (CRC) failure. Detection requires checksums or version numbers stored apart from the data, such as a parent block’s checksum or a database page’s sequence number. NVMe Protection Information (PI) misses it because a stale version of the same LBA still passes every PI check. Part 8 explains what PI does and does not check.

Figure 6.10 shows the first split. A failing command’s status code tells a NAND problem from a map problem. A media error, NVMe status type and code 02h/81h (Unrecovered Read Error), usually points to the NAND rather than FTL logic. An Internal Error, status type and code 00h/06h, or a vendor-specific status may point toward firmware behavior. That distinction decides whether to replace the drive, attempt recovery or escalate to the vendor.

First checks: logs and counters

Pull the Error Information log first, then the SMART / Health Information log. Here the fields that matter are Media and Data Integrity Errors, Unsafe Shutdowns, Percentage Used, Available Spare and the Critical Warning byte. Part 8 holds the full field reference.

After a failed recovery, the affected LBA ranges fail reads, Unsafe Shutdowns increments and Media and Data Integrity Errors rises. From the host this looks the same as media wear, because specific addresses are unreadable. To tell them apart, check Percentage Used and Available Spare. If both are clean and the drive is young, the failure more likely comes from recovery than from wear. The NAND at that location may still be intact while the map entry that points to it is gone.

Once anything recoverable has been copied off, and if no physical media damage is present, a secure erase and reinitialization is an option short of replacement, though it may not clear the fault.

What the FTL hands to garbage collection

The map the FTL keeps says which pages are live and which are stale, and that is the input garbage collection works from.

Real drives implement these policies in firmware, so two drives with the same NAND and controller can behave differently. ServeTheHome’s reviewer measured one drive that slowed once it was 67% full, on the firmware it arrived with, and a later ADATA firmware fixed it on the same hardware. He guessed the cause was the newness of the controller. One drive and a reviewer’s guess do not make a rule, but they show that firmware version is worth noting when comparing drives.

Figure 6.11 places this part in the series. Part 7 builds on this map. Every overwrite leaves a stale page behind, and garbage collection decides which blocks to reclaim, how to balance that work against host I/O and how to spread wear across the drive.