NAND flash can't overwrite a page in place — a whole block (here 8 pages) must be erased before any of its pages can be rewritten. So the flash translation layer (FTL) never overwrites: it writes the new copy to a free page elsewhere, marks the old page invalid, and later garbage-collects a block by copying its remaining valid pages out and erasing it.
Write Amplification (WA) = physical pages written / logical pages written
Lifespan remaining = 1 − (max block erase count / rated P/E cycles)
Every erase consumes one of the block's rated program/erase (P/E) cycles (≈3,000 for typical mobile TLC NAND). The problem: plain garbage collection only erases blocks that already contain garbage. A block holding cold data (a photo you never touch again) never accumulates garbage, so GC alone never erases it — every P/E cycle lands on the shrinking pool of blocks cycling your app's hot data, which wear out and fail long before the drive is actually full.
- Wear Leveling: ON — adds static wear leveling: when the least-worn block sits far behind the most-worn one, its valid (cold) data is proactively relocated so that block re-enters the write rotation. Erase counts across all blocks stay close together.
- Wear Leveling: OFF — only dynamic GC runs. Cold blocks stay pristine (dark blue, 0 erases) while hot blocks (red) race toward the rated limit — the true failure point, even though the device looks "half worn" on average.
- Cold data slider — the fraction of capacity written once and left alone, e.g. photos/videos vs. constantly-rewritten app cache/session state.
- GC reserve — how many blocks the FTL keeps pre-erased as over-provisioning headroom before it must garbage-collect under write pressure.
This is the same mechanism real mobile flash controllers (eMMC/UFS) run continuously and invisibly under Android's SharedPreferences, SQLite/Room files and app caches described in the source article — it's why a phone that "isn't full" can still develop bad blocks.