§44.4–44.7Flash Performance, the FTL, and Log-Structuring

Now that we know how raw flash behaves, we can build an actual SSD out of it.

44.4 Performance and Reliability

The raw operations have very different costs, and packing more bits per cell slows them further:

The main reliability worry is wear out wear out Flash's main reliability limit: each program/erase (P/E) cycle leaves a little extra charge in a block until 0s and 1s can no longer be told apart and the block dies. Rated lifetimes are ~10,000 P/E cycles (MLC) to ~100,000 (SLC). Avoiding uneven wear is why SSDs do wear leveling. defined in ch. 44 — open in glossary : every program/erase (P/E) cycle leaves a little extra charge in a block, until 0 and 1 can no longer be told apart and the block dies (rated ~10,000 P/E cycles for MLC, ~100,000 for SLC). There’s also disturbance — reading or programming a page can flip bits in neighbors.

44.5 From Raw Flash to an SSD: The FTL

An SSD wraps flash chips (plus some volatile SRAM and control logic) behind the standard block interface. The brains is the flash translation layer (FTL) flash translation layer The FTL: the SSD's control logic that presents a normal logical block interface while translating client reads/writes into low-level flash read/erase/program operations. It aims for high performance (low write amplification, chip parallelism) and reliability (wear leveling), typically via a log-structured design + a mapping table. defined in ch. 44 — open in glossary , which turns client reads/writes on logical blocks into low-level read/erase/program on physical pages:

Two FTL goals drive everything: keep performance high (use many chips in parallel and minimize write amplification write amplification The ratio of write traffic the FTL actually issues to the flash divided by the write traffic the client issued to the SSD. Extra writes come from garbage collection, block-mapping copies, and wear leveling. High write amplification wastes flash endurance and hurts performance; minimizing it is a core FTL goal. defined in ch. 44 — open in glossary — the flash write traffic issued divided by the client write traffic), and keep reliability high via wear leveling wear leveling The FTL activity that spreads program/erase cycles evenly across all blocks so they wear out at roughly the same time (rather than a few hot blocks dying early). Log-structuring helps, but the FTL must also periodically migrate long-lived data out of cold blocks so those blocks take their share of writes. defined in ch. 44 — open in glossary (spread erases evenly so all blocks wear out together, not a few hot ones early).

44.6 A Bad FTL: Direct-Mapped

The simplest FTL — direct-mapped direct-mapped ftl The naive FTL where logical page N maps straight to physical page N. Every write must read the whole containing block, erase it, and re-program all pages — causing huge write amplification, terrible write speed, and rapid wear of hot blocks. A bad idea, motivating the log-structured FTL. defined in ch. 44 — open in glossary — maps logical page N straight to physical page N. Reads are fine, but every write must read the whole containing block, erase it, then re-program all its pages plus the new one. That’s enormous write amplification (proportional to pages per block), write performance worse than a disk, and — because a repeatedly-overwritten logical block hammers the same physical block — rapid wear out. A bad idea on both counts.

44.7 A Log-Structured FTL

So most FTLs are log-structured log-structured ftl The dominant FTL design: on a write to logical block N, append the data to the next free page (logging) and record N → physical-page in a mapping table. This turns random writes into sequential ones (few erases), improves performance, and spreads wear — the same log idea as LFS, inside the device. Its costs: garbage collection and mapping-table size. defined in ch. 44 — open in glossary — the very idea from LFS, now inside the device. On a write to logical block N, the FTL just appends the data to the next free page and records N → physical-page in a mapping table:

This is a huge win: random client writes become sequential programs (erasing only occasionally), the costly read-modify-write is gone, and wear is spread across pages. The mapping table (kept in SRAM, and persisted — e.g. in each page’s out-of-band area — so it survives power loss) is the FTL’s version of LFS’s inode map. But log-structuring brings the same two costs LFS had: garbage from overwrites, and a potentially huge mapping table — the subjects of the next page.