The Big Asymmetry: Read, Program, and Erase
Why writing to an SSD is never as simple as it sounds.
Flash supports three operations, and they are wildly asymmetric in granularity and speed. This asymmetry is the single most important thing to internalize about SSDs.
| Operation | Unit | Relative speed | Notes |
|---|---|---|---|
| Read | page | fastest (~tens of µs) | random reads are cheap |
| Program (write) | page | slower (~hundreds of µs) | only onto an erased page |
| Erase | block | slowest (~ms) | resets a whole block of pages |
The rule that changes everything
You can only program a page that is currently erased. You cannot overwrite a page that already holds data. To reuse it, you must erase its entire block first.
So what happens when software "overwrites" a file? The SSD does not edit the old page. Instead it:
- writes the new data to a fresh, already-erased page somewhere else,
- updates its map so the logical address now points to the new page, and
- marks the old page as invalid (stale) — dead data that still occupies space.
An "overwrite" leaves a stale copy behind. Those stale pages accumulate until garbage collection reclaims them.
Over time, blocks fill up with a mix of valid and invalid pages. Eventually the SSD runs low on erased space and must clean up — that's garbage collection. And the cleanup itself causes extra writes, which is write amplification.
In the EyanaSSDSim paper & simulator. In the Live Simulator's block grid, this is precisely the color you see: a block darkens/greens according to how many of its pages are invalid. Watching blocks fill with stale pages and then snap back to empty after an erase is this asymmetry in action.