Two background jobs and a comparison remain.
44.10 Wear Leveling
Log-structuring and garbage collection already spread writes around, but there’s a gap: a block full of long-lived data that’s never overwritten is never garbage-collected — so it never gets its fair share of the write load, while other blocks wear out faster. So the FTL must occasionally do 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 proper: read the live data out of such a cold block and rewrite it elsewhere, freeing the block to take new writes. It costs extra I/O (more write amplification), but keeps all blocks aging at roughly the same rate.
44.11 SSD vs Hard Drive: Performance and Cost
Performance. With no moving parts, an SSD is essentially random-access. The dramatic difference is at random I/O:
| random read | random write | seq read | seq write | |
|---|---|---|---|---|
| Samsung 840 Pro (SSD) | 103 | 287 | 421 | 384 |
| Seagate 600 (SSD) | 84 | 252 | 424 | 374 |
| Intel 335 (SSD) | 39 | 222 | 344 | 354 |
| Seagate 15K.3 (HDD) | 2 | 2 | 223 | 223 |
Two things stand out. Random I/O: SSDs do tens–hundreds of MB/s where the disk manages ~2 MB/s. Sequential I/O: the gap shrinks — a disk is still respectable if all you do is stream. And notice SSD random writes often beat random reads — a happy side effect of the log-structured FTL turning random writes into sequential ones.
Cost. So why haven’t SSDs killed disks? Cost per GB: an SSD runs ~60¢/GB versus ~5¢/GB for a disk — still a ~10× gap. So large systems mix them: a little SSD for hot, performance-critical data; lots of cheap disk for cold bulk data. While the price gap holds, disks aren’t going anywhere.
44.12 Summary
Flash-based SSDs are everywhere now. Building one means taming flash’s quirks — erase-before-program and wear-out — with a flash translation layer that is usually log-structured (the same idea as LFS), paying the costs of garbage collection (write amplification) and mapping-table size (hybrid mapping helps), plus wear leveling to make the whole device age evenly. In one table:
| concept | what it is | |
|---|---|---|
| flash | flash: pages & blocks | read/program a page; ERASE a whole block first — and erase wipes the block; blocks wear out after many P/E cycles |
| ftl | flash translation layer | presents a normal block device; maps logical blocks → physical flash read/erase/program |
| log | log-structured FTL | append writes to free pages + a mapping table (the LFS idea in-device); turns random writes sequential, spreads wear |
| gc | garbage collection | reclaim dead pages left by overwrites (copy live out, erase block); adds write amplification, eased by trim + overprovisioning |
| map | mapping table | per-page is huge, per-block hurts small writes → hybrid mapping (log + data tables) or caching hot mappings |
| wear | wear leveling | migrate long-lived data off cold blocks so every block gets its share of P/E cycles |
This is just the first step — SSD design is a deep field, and the log-structured theme you’ve now seen at the file-system level (LFS) and the device level (the FTL) recurs throughout modern storage.
Check yourself: wear leveling, performance, and cost
1.Log-structuring and GC already spread writes. Why is explicit wear leveling still needed?
2.Where is the performance difference between SSDs and hard drives most dramatic?
3.Why do SSD random WRITES often outperform SSD random READS?
4.Given SSDs outperform disks even sequentially, why haven't they replaced hard drives?
5.Given the performance/cost trade-off, how are large storage systems often built?
6.What recurring design idea appears at BOTH the file-system level and the SSD device level?