The Flash Translation Layer (FTL) and Address Mapping
The tiny operating system inside every SSD that hides flash's quirks.
Your computer thinks it's talking to a simple array of numbered blocks — logical block addresses (LBAs), or in page terms, logical page numbers (LPNs). But flash can't be overwritten in place, so those logical addresses can't map to fixed physical locations. The Flash Translation Layer (FTL) is the firmware that bridges this gap.
The FTL keeps a mapping table: logical page number (what the host asks for) → physical page number (where the data actually lives). Every write picks a fresh physical page and updates this table.
Writes are appended to fresh pages (log-structured); the table is repointed and the old page becomes invalid.
Log-structured writing
Because every write goes to a fresh erased page, the FTL effectively writes data like a never-ending journal — always appending. This is called log-structured writing. It's fast (no searching for a spot), but it steadily consumes erased pages and leaves invalid ones behind, which is why garbage collection is unavoidable.
What the FTL is responsible for
- Address mapping — the LPN→PPN table above.
- Data placement — which channel/die/plane a write goes to (the allocation scheme).
- Garbage collection — reclaiming invalid pages by erasing blocks.
- Wear leveling — spreading erases so no block dies early.
Analogy. The FTL is a hotel concierge. Guests (logical addresses) never know or care which physical room they're in; the concierge keeps a ledger and can move guests between rooms freely, as long as the ledger stays correct.
In the EyanaSSDSim paper & simulator. EyanaSSDSim implements a real FTL: a forward map (LPN→PPN), a reverse map (PPN→LPN) used during garbage collection, and per-block valid/invalid counters. The simulator's correctness depends on keeping these consistent — a class of bug the paper's rebuilt engine specifically fixed.