This 2D companion places the same NAND translation-layer mechanics on an erase ring instead of the 3D version's bar-height grid, and adds a statistic the 3D scene doesn't compute: a real Gini coefficient of the erase-count distribution across blocks — the standard inequality measure from economics, applied here to P/E cycles instead of income. 0 means every block has taken exactly the same number of erases; values approaching 1 mean nearly all wear has piled onto a tiny handful of blocks while the rest sit pristine.
Write Amplification (WA) = physical pages written / logical pages written
Gini(erases) = (2·Σᵢ i·xᵢ) / (n·Σᵢ xᵢ) − (n+1)/n (xᵢ sorted ascending, i = 1..n)
Lifespan left = 1 − (max block erase count / rated P/E cycles)
NAND can't overwrite a page in place — a whole block (8 pages here) must be erased before any of its pages can be rewritten. The flash translation layer (FTL) never overwrites in place: it programs the new copy into a free page elsewhere, marks the old page invalid, and later garbage-collects a block by relocating its still-valid pages and erasing it. Every erase consumes one of the block's rated program/erase (P/E) cycles (≈3,000 for typical mobile TLC NAND).
- Wear Leveling: ON — adds static wear leveling: once the least-worn all-valid block falls far enough behind the most-worn one, its cold data is proactively migrated so that block re-enters the erase rotation. The Gini index stays low and the ring stays one even shade.
- Wear Leveling: OFF — only dynamic GC runs, which only erases blocks that already contain garbage. Blocks holding write-once cold data never accumulate garbage, so they never get reclaimed: they stay dark blue at 0 erases while a shrinking pool of hot blocks turns red and races toward the rated limit — the Gini index climbs steadily even though the device "looks" only lightly worn on average.
- Cold data slider — the fraction of capacity written once and left alone (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 reclaim 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 — it's why a phone that "isn't full" can still develop bad blocks, and why the wear-inequality index (not just the average erase count) is what actually predicts which block dies first.