Today
- Flash-based SSD
- Solid State => Circuitry
- persistent storage
- basic characteristics
- from “row” flash => storage device
Basics
- NAND Flash
- “trap” charge, encode bit(s)
- Bank/Chip
- operations
- read (page) (~2KB, 4KB)
--------------------------------- | |page| | | --------------------------------- | block |- erase (block) (~256KB)
- program (page)
- to write
- erase entire block
- then, you can program each page within block exactly once
- if you want to overwrite, must erase/prog again
- Performance
- read 10s of microseconds
- much faster then hard drive
- erase a few milliseconds
- program 100s of microseconds
- read 10s of microseconds
- Reliability
- “wear out”
- once you erase/program block “too many” times
- it stops working
- “to many”: 10k ~ 100k times
- “wear out”
SSD: Block-level Device
- API: read, write block
- Map to read, erase/program
- Parallel storage device
|------------------------
| ------------ ------ |
| |Controller| |DRAM| |
| ------------ ------ |
| --- --- |
| |F| |F| ... |
| --- --- |
-------------------------
Naive Approach Direct-mapped
- to read:
- read (easy)
- to update a block:
- read block
- erase
- program it again
- Issue
- I/O amplification (bad performance)
- crash could lose data
- wear things out
Log-structuring
- treat flash blocks like a log
Block1 -------------------------------------------------- | | | | | | | | --------------------------------------------------- How to find anything?
- Flash Translation layer (FLT)
- Implemented in controller + DRAM
- (Map page->location on flash)
- Problems:
- FTL recovery in case of crash
- When writing make sure to record mapping info
- Need to do garbage collection
- background activity
- Wear leveling
- background activity
- Stpace overhead
- FTL recovery in case of crash
- Flash Translation layer (FLT)