Wear leveling and flash controllers: Question bank

This bank builds on the parent and on Garbage Collection, Over-provisioning and TRIM, SLC MLC TLC QLC, NAND vs NOR Flash, Bad Block Management and ECC, Log-Structured File Systems, and SSD Architecture. Everything you need to answer is defined in the parent — nothing new is assumed here.

True or false — justify

A block can be programmed one page at a time but must be erased all at once

True — read/write granularity is a page (~4 KB) while erase granularity is a whole block (~256 KB); this asymmetry is why out-of-place writing and GC exist at all.

Flash can flip an individual bit from 0 back to 1 without touching its neighbours

False — you can only clear bits to 1 by erasing the entire block; you can program 1→0 per bit, but the reverse is a block-wide operation.

Wear leveling reduces the total number of physical writes the drive performs

False — it often adds writes (static relocation, GC copies); what it reduces is the variance in wear across blocks so no single block dies early.

With dynamic-only wear leveling, cold data can end up parked forever on a fresh, low-wear block

True — dynamic leveling only cycles the actively-written blocks, so untouched data (a movie you never open) sits on a young block and never joins the rotation; that's precisely the gap static leveling fills.

A WAF of exactly 1 means garbage collection never runs

False — WAF = 1 happens when GC only ever reclaims blocks that are 100% stale (

u = 0

), so copies cost nothing; GC still runs, it just copies zero valid pages.

WAF below 1 violates the amplification formula and is therefore impossible

False — the GC formula

WAF = \frac{1}{1 - u}

gives

\geq 1

, but transparent compression/dedup is a separate mechanism that can write fewer bytes than the host sent, pushing the measured WAF under 1.

The FTL is optional — an OS could talk to raw flash directly

Technically yes but practically no — some systems do manage raw flash (see Log-Structured File Systems), but then the filesystem must implement wear leveling, GC, and bad-block handling itself; the FTL just moves that job into the controller.

Over-provisioning helps endurance because the spare cells directly absorb wear

Misleading — the spare capacity's real benefit is letting GC wait longer, so victim blocks are emptier (lower

u

), which lowers WAF; it's an indirect effect, not the spare cells "taking hits."

Static wear leveling costs write endurance now to save endurance later

True — relocating cold data is an extra write today, but it frees a fresh block into the rotation so the whole drive ages evenly and outlives a dynamic-only scheme.

Spot the error

"Logical block 100 always lives at physical block 100, we just erase and rewrite it in place."

The error is in place — the FTL remaps LBA→PPA on every write, sending each new version to a fresh page and marking the old one stale; there is no fixed logical-to-physical binding.

"Since GC erases stale pages, it never touches valid data."

Wrong — GC first copies the still-valid pages out of the victim block, then erases; those copies are exactly the source of write amplification.

WAF = \frac{N ( 1 - u ) + u N}{N}

, so WAF simplifies to 1 always."

The denominator is wrong — you divide by host writes

N (1 - u)

, not by

N

; dividing by the useful part gives

\frac{1}{1 - u}

, which is generally above 1.

"TLC stores more bits per cell, so it must also endure more P/E cycles."

Backwards — packing more voltage levels per cell (see SLC MLC TLC QLC) makes each cell more fragile, so TLC/QLC endure fewer P/E cycles (~1000 or less) than SLC (~100000).

"A block reported bad by ECC means the whole drive is failing."

No — bad blocks are expected and retired individually by Bad Block Management and ECC; the drive keeps working using spare blocks until the reserve is exhausted.

"Because writes move data around, reads also become slower and random."

The FTL map is looked up in fast RAM, so a read is still a single indirection then a direct page fetch; movement affects write bookkeeping, not read latency in the normal case.

"If victim blocks are 100% valid, GC just erases them and reclaims full space."

Impossible — a 100% valid block has no stale space to reclaim; GC would have to copy every page elsewhere (

u \to 1

WAF \to \infty

), which is why controllers never pick fully-valid victims.

Why questions

Why can't flash simply overwrite data the way a hard disk does?

Because a bit can only be reset to 1 by erasing its entire block; overwriting one page in place would require erasing all 64 pages around it, so the controller writes to a fresh page instead.

Why does more free space (over-provisioning) lower write amplification?

With more free blocks the controller can defer GC until a victim block is mostly stale (small

u

), and since

WAF = \frac{1}{1 - u}

, a smaller

u

means fewer valid pages copied per erase.

Why is flash described as "log-structured underneath"?

Every write goes to a new physical page and old copies become garbage, exactly like appending to a log; this mirrors Log-Structured File Systems and is why GC is needed to reclaim the stale tail.

Why does the FTL map need to live in fast memory, not on the flash itself?

The map is consulted on every read and write; if each lookup required a flash access the drive would be crippled, so a working copy sits in RAM (rebuilt from flash on power-up).

Why does concentrating writes on a few "hot" logical addresses threaten the drive even though those addresses barely change size?

Without indirection those addresses would map to fixed physical blocks that exhaust their P/E budget in days while the rest of the chip stays fresh — the FTL + wear leveling break that fixed binding.

Why can a single host write of 4 KB cause far more than 4 KB written to flash?

If that write forces GC on a partly-valid victim, the controller must copy the victim's valid pages before erasing, so the physical bytes written include those ride-along copies — the essence of WAF.

Edge cases

What is WAF when garbage-collected blocks are entirely stale (

u = 0

WAF = \frac{1}{1 - 0} = 1

— the best case: nothing valid is copied, so physical writes equal host writes.

What happens to WAF as victim blocks approach fully valid (

u \to 1

WAF \to \infty

— nearly every page must be copied before an erase, so the controller burns endurance copying data and reclaims almost no space; well-designed GC avoids picking such blocks.

A brand-new drive with plenty of free blocks and no stale pages — does GC run and what is its cost?

GC essentially doesn't run yet because there are free blocks to write into directly; amplification stays near 1 until the drive fills and stale pages accumulate.

A drive that is 100% full of cold, never-rewritten data — what keeps its blocks from wearing unevenly?

Only static wear leveling can help, by periodically relocating that cold data so its blocks rejoin the rotation; dynamic leveling alone would leave the wear frozen wherever it landed.

What happens to a drive's endurance the instant its pool of spare/bad-block-reserve is exhausted?

Once no spare blocks remain to replace worn or bad ones (see Bad Block Management and ECC), the controller can no longer relocate failing data and the drive typically drops to read-only or reports failure.

Is a WAF of 1 the theoretical minimum for a controller with no compression?

Yes for the GC mechanism alone — you can't do better than copying zero valid pages (

u = 0

); only a separate compression/dedup layer can beat 1 by writing fewer bytes than the host requested.

Recall One-line self-test

Cover every answer above, redo the "Spot the error" set only, and check you fixed and explained each — the reasoning is the point, not the verdict. Ready? ::: If any justification was hazy, reread the WAF derivation and the dynamic-vs-static section in the parent note.