A Space-Efficient Flash Translation Layer for Compactflash Systems

What kind of paper is this?

• Biggish idea. (It's an optimization paper, but it's driving towards the convergence of LFS and Flash.)

The Story

• Flash is replacing spinning disk in many systems for persistent storage.
• Flash can only overwrite data if it is first erased and erasures happen in units larger than writes (erase blocks rather than file system blocks).
• A design akin to a log-structured file system works well for this.
• Flash drives now exhibit much better performance.

Flash 101

• Flash is a form of persistent memory. (This paper talks about NAND flash.)
• Supports random access without any mechanical delay (i.e., rotational or seek).
• Page: what we call a disk block -- unit of read/write (2KB at the time; 4 KB now).
• Block: unit of erasure: 4KB - 128 KB at the time; now typically at least 64 KB and frequently larger.
• Flash drives typically have some SRAM as well as flash. Logical block to physical block mapping is stored in SRAM.
• Persistent mappings are stored in the spare area.

FTL Design

• Goal: manage most space on the device by the (erase) block and only a few at the finer-grain page level.
• Updating (overwriting) an existing page.
  1. Allocate a log block (these are pre-erased).
  2. Write the updated page to the log block (starting at the beginning).
  3. Write the logical address of the page into the spare area.
  4. Note: each log block corresponds to a data block, so that if you have writes going to multiple data blocks, you have to a log block for each data block being modified.
• Reading a page
  1. Check if page is present in a log block (using a mapping in SRAM).
  2. If not in a log block, read from the actual location (from data blocks).
• Merging log blocks
  1. Triggered if a log block fills.
  2. Allocate another free block; fill that block with pages either from the log block, or if a particular page has not been updated, fill with a block from the original data block.
  3. The new block becomes the official data block.
  4. The log block is erased and returned to the pool of available blocks.
  5. The original data block is erased and returned to the pool of available blocks.
  6. Optimization: if all the pages in a data block were written, in order, then the log block can just become the new data block.
• The Map
  • Stored in map blocks, organized at the page level.
  • Updated map entries are written to map blocks, just like pages are written to log blocks in data writes.
  • The map directory (stored in SRAM) locates all the map blocks.
  • Managed so that merge operations affect only a single block in the map.
  • Reclaiming map blocks is even more like LFS cleaning that the merges.
  • Map lookup
    1. Use high order bits of logical page address to find the page containing the right map entry.
    2. If not already in SRAM, read it here.
    3. Use middle bits of logical address to index to precise entry in the page.
    4. Construct physical page address by concatenating the page's block offset to the physical block address obtained in the previous step.

Eval

• Prototype
• Simulator: replacement scheme, page-level remapping, current
  • Page level remapping: greedy and cost-benefit
  • Current scheme without map blocks
• Workloads
  • Cameras: take photos, browse, erase.
  • PDA: web, mp3, file copy
  • Andrew benchmark
• Metrics (relative to ideal)
  • Number of extra erase blocks
  • Number of extra page writes
• Results:
  • High order bit: this logging approach reduces erases to be closer to that of page-mapping, with significantly less overhead.
  • Behavior is super workload sensitive (see 5c).
  • Wear leveling works.