Flash Translation Layers and NAND Mapping
An SSD or flash drive does not store a logical sector at a fixed physical address — the controller continuously rewrites the map between the two, and that map is often what recovery actually needs to rebuild.
Why NAND cannot be overwritten in place
NAND flash has two different operating granularities: a page can be programmed or read individually, but erasure only happens at the larger block level that contains many pages. Changing one logical page therefore cannot simply mean “erase that page, write the new version to the same physical address.” Instead the controller almost always writes the new version to a different, already-erased physical location and marks the old copy invalid. This out-of-place write behavior is the reason flash needs a flash translation layer (FTL) at all, and the direct cause of write amplification, wear leveling and garbage collection further down this page.
Logical-to-physical mapping is a live, continuously updated table
Vendor documentation from KIOXIA describes an internal L2P (logical-to-physical) mapping table that records which physical NAND block and page currently holds each host-visible logical block address, and that table is itself system data the controller updates on every write. A simplified example: logical block 1000 might point to NAND block 231, page 17 today, and to block 882, page 3 tomorrow after garbage collection or wear leveling moves it — with nothing at the file-system level revealing that the physical location changed. The practical consequence for recovery: the logical sector address is a controller-maintained abstraction, not a permanent physical location, and reading physical NAND in address order does not reproduce logical sector order.
Wear leveling moves data that never logically changed
Wear leveling exists to spread program/erase cycles evenly across NAND blocks so a small subset does not wear out far ahead of the rest. Its side effect is that a logical sector whose contents have not changed at the file-system level can still be relocated physically by controller background maintenance. A file occupying consecutive logical blocks may therefore be scattered across different dies, planes, chips, blocks and write generations by the time it is examined at the chip level — one reason chip-off reconstruction depends on controller-specific knowledge rather than a simple physical read.
Garbage collection updates the map before it erases anything
Garbage collection is commonly described as a multi-stage background process: identify a block containing a mix of valid and invalid pages, copy the still-valid pages to a different block, update the L2P table to point at their new location, erase the original block, and return it to the pool of free blocks. Two recovery-relevant consequences follow: deleted or superseded data can remain physically present in NAND for a period after the controller stops exposing it logically, and the timing of the eventual physical erase is controlled by firmware, workload and power state — not by a fixed, externally observable countdown. See TRIM, Deallocate and Garbage Collection for how this interacts with file deletion specifically.
Bad-block management is transparent remapping, not a hole in the disk
NAND ships with some factory bad blocks and develops more over its service life; a managed-flash controller retires blocks it judges unreliable and substitutes reserved replacement blocks in their place. A raw NAND dump therefore includes physical blocks the host never treated as ordinary user storage, and the controller's own record of which blocks are retired can differ from any factory bad-block markers printed or programmed at manufacture. Reading NAND in simple physical order does not yield logical sector order partly because of this substitution.
Multiple physical generations can coexist
Because writes go to new locations rather than overwriting in place, a single logical address can briefly have more than one physical copy on the NAND at once — an old, soon-to-be-garbage-collected version and a new, currently mapped version. Recovery software that ignores the mapping layer and reads physical NAND directly may encounter both, with no reliable way to tell which is current without reconstructing the L2P table itself.
What happens when the translator is lost
If the mapping metadata is corrupted, incomplete or inaccessible — through firmware failure, abrupt power loss during a metadata update, or physical damage to the region where it lives — the controller may no longer be able to answer “which physical page currently represents logical block N?” correctly. NAND can be completely intact at the electrical level and still not be assemblable into a coherent logical drive, because the map that gave the pages their sector identity is what is actually missing.
Why a raw NAND dump is not a disk image
A raw NAND dump is a set of physical pages in physical order, still carrying ECC and spare-area fields, still possibly scrambled, and not yet arranged into logical sector order. A disk image, by contrast, is the result the original controller already produces on every ordinary read: NAND that has been read, error-corrected, descrambled, and mapped into logical order. That is why acquiring a stable logical read through the working controller is usually worth more than a raw chip dump — the controller is, in effect, the most complete NAND-reconstruction tool available for its own flash. See Chip-Off, ISP and Monolithic Flash Recovery for what raw acquisition actually involves when a working controller is not available.
Recover the logical map and the physical pages together. Physical NAND without its mapping metadata is a pile of pages; a mapping table without the pages it describes is empty. Either one alone is usually insufficient.
Related: SSD Recovery Fundamentals · SSD Firmware, Translator and Controller-Level Recovery · Chip-Off, ISP and Monolithic Flash Recovery · TRIM, Deallocate and Garbage Collection · SSD Controller Failure · USB Flash Drive Failure