4.1.11 · D2Memory Technologies

Visual walkthrough — Wear leveling and flash controllers

1,808 words8 min readBack to topic

Step 1 — Draw the thing we are counting: a block of pages

WHAT. A flash block is a fixed grid of small boxes called pages. Let the letter just mean "how many pages are in one block" — a plain count, like 64. Nothing mysterious: is the number of little squares in our picture.

WHY start here. Every write, every erase, every copy in this whole story is measured in pages. If we don't fix a unit to count in, "write amplification" is just a vibe. The block is our ruler.

PICTURE. Below, one block drawn as a strip of squares. Each square is one page. We will colour these squares in later steps; right now they're all blank — a brand-new, freshly-erased block.

Figure — Wear leveling and flash controllers

Step 2 — Why data goes stale: writing never overwrites

WHAT. When the host rewrites some data, flash cannot change the old square in place. The controller writes the new version into a fresh square and marks the old one as garbage. We'll paint garbage squares pink and call them stale. Live, still-wanted squares we paint blue and call valid.

WHY. This is the erase-before-write rule from the parent. Because old copies can't be scrubbed one-at-a-time, they pile up as pink squares scattered through the block. The block slowly fills with a mix of blue (needed) and pink (dead-weight).

PICTURE. The same block, now partly used: some squares blue (valid), some pink (stale). Notice the pink squares are wasted space we can't reuse until we erase the entire block.

Figure — Wear leveling and flash controllers

Step 3 — Name the mix with one number: the valid fraction

WHAT. Instead of tracking exactly which squares are blue, we track just their proportion. Let

  • The top counts blue squares only.
  • The bottom is , the whole strip.
  • So is a slider from (no blue at all) to (every square blue).

WHY this tool and not raw counts? Because the final answer won't depend on how big the block is — only on how full of live data it is. A number between 0 and 1 is exactly the right handle: it lets one formula cover a 64-page block and a 512-page block identically.

PICTURE. The block with a slider underneath: drag left → mostly pink (small ), drag right → mostly blue (large ). The blue-shaded bar shows the size of .

Figure — Wear leveling and flash controllers

Step 4 — Split the block into "must copy" and "was wasted"

WHAT. Take our -page block. The blue part is pages. The pink part is everything else, pages.

  • — the squares we are forced to rescue (copy elsewhere) before we can erase.
  • — the squares that were pure garbage; erasing them costs us nothing but gives back real free space.

WHY split like this? Because these two piles have completely different jobs. One pile is work we do for free space we don't even keep (the copies). The other pile is the actual free space we win. Amplification is the ratio between them — so we must separate them first.

PICTURE. The block sliced into a blue segment of length and a pink segment of length , each labelled.

Figure — Wear leveling and flash controllers

Step 5 — Watch garbage collection actually run

WHAT. Garbage Collection cleans this block in three moves:

  1. Copy the blue pages into a fresh block (that's real writes to flash).
  2. Erase the strip — all squares become blank again.
  3. Now the strip has blank pages, but of them are already spoken for by the copies we just made.

So after one cleanup, the genuinely-new free space we can hand back to the host is:

WHY. This is the accounting heart of the whole page. The host thinks it got fresh pages. But to hand those over, the drive secretly also did copy-writes. The host never asked for those copies — they're pure overhead.

PICTURE. Three panels left-to-right: (a) dirty block, (b) blue pages flying out to a fresh block via arrows (the copies), (c) the erased block, now blank, with the fresh block holding the rescued blue pages.

Figure — Wear leveling and flash controllers

Step 6 — Total the writes and form the ratio

WHAT. Add up every write that hit the flash during that cleanup cycle, then divide by the writes the host actually asked for.

  • Numerator = host's own data plus the rescued copies . Together they sum to .
  • Denominator = only the host's data — the useful part.

Simplify the numerator: . So

WHY divide? "Amplification" means a ratio: how many bytes truly hit the flash per byte the host requested. Division is the only operation that answers "how many times bigger?". The cancels top and bottom — proving the block size never mattered, only does.

PICTURE. A fraction drawn as two stacked bars: the top bar (length ) split blue+pink; the bottom bar (length ) just the pink-derived useful part. The eye sees WAF as "how much taller the top bar is."

Figure — Wear leveling and flash controllers

Step 7 — The edge cases (never skip these)

WHAT & WHY. A formula you can't reason about at its extremes is a formula you don't understand. We test all three corners of the -slider.

  • (all pink, no blue). . Picture: an all-pink block. Nothing to rescue → erase gives free pages for zero copies. This is the dream and the hard floor of the GC formula: you can never do better than 1 by cleaning.
  • (almost all blue). . Picture: an all-blue block. To free even one page you copy nearly the whole block. This is the disaster GC tries to avoid — it explains why the drive picks the emptiest victim block, and why Over-provisioning and TRIM (extra spare space) keeps low.
  • exactly (fully valid). Division by is undefined — and rightly so: a fully-valid block has no free space to gain, so cleaning it is meaningless. The math refuses because the action is pointless.

PICTURE. Three tiny blocks side by side (all-pink, half, all-blue) with their WAF values , , printed under them, and the curve swooping up on the right.

Figure — Wear leveling and flash controllers

The one-picture summary

Everything collapses into one image: the -slider on the bottom, the block above it changing colour, and the WAF-curve climbing from at the left to a wall at . Slide right (blocks fuller) → curve rockets up → drive dies faster. Add spare space → slide left → curve calms down → drive lives longer.

Figure — Wear leveling and flash controllers
Recall Feynman retelling — say it like a story

Picture a strip of little boxes: that's a flash block. Some boxes still hold data you need (paint them blue), some hold junk you already replaced (paint them pink) — because flash can't erase junk one box at a time. To recycle the strip you must burn the whole thing, so first you rescue every blue box by copying it somewhere fresh. Those copies are extra writes nobody asked for. Call the share of blue boxes. Out of the whole strip , the copies cost you writes, and the truly-new space you win back is only . Divide total writes by the useful writes and the strip-size cancels, leaving . If the strip was all junk () you copy nothing — amplification is 1, perfect. If the strip was nearly all blue () you copy almost everything to free almost nothing — amplification blows up to infinity. That single curve is why keeping empty space (over-provisioning) is the secret to a long-lived SSD.

Recall Quick self-test

If GC picks blocks that are 50% valid, what is WAF? ::: As , WAF approaches what? ::: (the ideal floor) Why does block size not appear in the final formula? ::: It cancels top and bottom in Step 6. What real mechanism lets you keep small? ::: Over-provisioning and TRIM — extra spare space lets GC wait for emptier victims.