Flash Translation Layer (FTL)

An overwrite can place new contents in a different flash page while keeping the host address unchanged. The map identifies the current location; the superseded page can remain physically programmed until its block is erased. Invalidation is not erasure. [1]

Before reclaiming a block, garbage collection preserves any still-live pages elsewhere. Wear leveling has a different objective: spreading erase wear. The policies interact, but reclaiming space and balancing wear are not interchangeable tasks. [1]

Mapping granularity and map residency are separate choices. Page-level mapping need not keep its entire table in RAM: DFTL selectively caches entries and stores translation pages in flash. Its Global Translation Directory locates those pages. [2]

In the demand-mapping architecture described by LearnedFTL, a cache miss can require a translation-page read before the requested data read. This dependency explains possible extra I/O, not a universal two-times latency multiplier: cache behavior, scheduling and other work also matter. [3]

Metadata writeback can add work beyond fetching a missing mapping; see the linked analysis. [2]

Recovery must reconstruct usable mappings and distinguish current data from obsolete copies. Agrawal and colleagues discuss persistent metadata and backup energy; these are design considerations, not proof that a particular SSD implements a specified crash contract. [1]

Raw flash can use a different stack. Linux UBIFS sits on UBI volumes over MTD; UBI provides wear leveling and bad-block management but still exposes flash erase semantics. It should not be described as a conventional block-device FTL. [4]

For a device investigation, record the model and firmware, access range, read/write mix and steady-state conditions. Check cache behavior separately from persistence guarantees, then use the linked analyses for mapping-footprint examples and explicit recovery models.