This page is the exercise machine for the parent topic . The parent gave you the two engines that drive every number here:
Recall The two formulas you will use on this page
The write amplification factor measures how much extra writing garbage collection forces:
WAF = data the host asked to write data physically written to flash = 1 − u 1
where u is the average fraction of still-valid pages in the blocks the controller erases. The lifetime of a drive is total endurance divided by daily physical wear:
lifetime = ( host writes/day ) × WAF ( capacity ) × ( P/E rating )
Every symbol above was earned in the parent note. If any feels unfamiliar, re-read it before continuing — this page assumes nothing new except arithmetic.
The whole topic, viewed as "what can the exam throw at me," lives inside a small grid. Each cell is a regime of the input u (the valid fraction) or a different quantity being solved for . We will hit every cell.
Cell
What makes it special
Covered by
A. u → 0 (mostly stale)
Best case, WAF → 1
Ex 1
B. mid u (typical drive)
Normal working point
Ex 2
C. u → 1 (mostly valid)
Danger zone, WAF → ∞
Ex 3
D. degenerate u = 1
Formula divides by zero — what does it mean ?
Ex 4
E. solve backwards
Given WAF, find u
Ex 5
F. lifetime word problem
Combine WAF + endurance + daily load
Ex 6
G. over-provisioning effect
How free space lowers u and buys years
Ex 7
H. dynamic-only trap
Uneven wear across hot/cold split, no formula plug
Ex 8
I. exam twist: WAF < 1
Compression breaks the "amplification only adds" instinct
Ex 9
Intuition The one picture behind cells A–D
WAF = 1/ ( 1 − u ) is a curve that hugs the floor for small u and then rockets upward as u nears 1. Everything about "keep blocks empty before erasing" is just: stay on the flat part of this curve.
Worked example Example 1 — Cell A: mostly-stale victim blocks (
u → 0 )
Garbage collection always finds blocks that are only 5% valid (u = 0.05 ). Find WAF and say what it means.
Forecast: Guess first — will WAF be near 1, near 2, or huge? (The blocks are almost empty…)
Step 1. Identify u = 0.05 .
Why this step? The formula needs the valid fraction; "5% valid" is exactly that, no conversion.
Step 2. WAF = 1 − 0.05 1 = 0.95 1 = 1.0526 .
Why this step? Plug straight into 1/ ( 1 − u ) ; almost nothing valid means almost nothing gets copied along.
Verify: For every 100 pages erased, only 5 were valid and copied — so per useful free page we do about 5/95 ≈ 0.053 extra writes, matching the 0.0526 excess above 1 . Near-ideal. ✓
Worked example Example 2 — Cell B: a typical drive (
u = 0.70 )
GC targets blocks that are 70% valid . Find WAF.
Forecast: More than half the block rides along for free — expect WAF well above 1.
Step 1. u = 0.70 .
Step 2. WAF = 1 − 0.70 1 = 0.30 1 = 3.333 .
Why this step? 0.30 is the free fraction 1 − u ; dividing by it is dividing host-useful work into total work.
Verify: Out of 100 pages, 70 copied + 30 freed for the host. Total writes = 70 + 30 = 100 ; useful = 30 ; ratio 100/30 = 3.33 . ✓ Matches the parent's Example 1.
Worked example Example 3 — Cell C: the danger zone (
u = 0.95 )
A poorly-provisioned drive is forced to erase blocks that are 95% valid . Find WAF.
Forecast: Almost every page must be copied before erase — this should be painful .
Step 1. u = 0.95 .
Step 2. WAF = 1 − 0.95 1 = 0.05 1 = 20 .
Why this step? The free fraction is a tiny 0.05 ; dividing by a tiny number gives a huge result — geometrically, we are far up the steep tail of the s01 curve.
Verify: 95 copies for every 5 freed pages: total 100 , useful 5 , ratio 20 . A drive here burns endurance 20 × faster than ideal. ✓
Worked example Example 4 — Cell D: what happens at exactly 100% valid?
Suppose the only candidate block for GC is 100% valid (u = 1 ). What does the formula say, and what does it mean physically?
Forecast: The formula has 1 − u in the denominator. What is 1/0 ?
Step 1. 1 − u = 1 − 1 = 0 .
Why this step? Before blindly dividing, check the denominator — this is the "look for zero inputs" habit.
Step 2. WAF = 0 1 is undefined (it diverges to + ∞ ).
Why this step? Division by zero has no numeric value; mathematically WAF blows up.
Step 3. Read the physics. A fully-valid block yields zero free pages after copying all N of them elsewhere — so GC does work but reclaims nothing. The controller must never pick a 100%-valid block ; it would be pure loss.
Why this step? The undefined answer is telling us the operation is forbidden, not that the drive explodes.
Verify: Take the limit from below: u = 0.99 ⇒ WAF = 100 ; u = 0.999 ⇒ WAF = 1000 . As u → 1 − the value grows without bound — consistent with "undefined at exactly 1." ✓
u = 1 gives WAF = 1 because it's full."
Why it feels right: "Full" sounds like "done, no waste."
The fix: Full of valid data means everything must be copied and nothing is freed — the worst case, not the best. Best case is full of stale data (u = 0 ).
Worked example Example 5 — Cell E: reverse the formula
A controller reports a measured WAF = 4 . What valid fraction u is GC operating at?
Forecast: WAF of 4 is worse than the typical 3.33 — so u should be a bit above 0.70.
Step 1. Start from WAF = 1 − u 1 and set it equal to 4 .
Why this step? We know the output, want the input — algebra, not plugging.
Step 2. Invert both sides: 1 − u = WAF 1 = 4 1 = 0.25 .
Why this step? Taking reciprocals of both sides isolates 1 − u cleanly.
Step 3. Solve: u = 1 − 0.25 = 0.75 .
Why this step? Subtract to free u .
Verify: Plug back: 1 − 0.75 1 = 0.25 1 = 4 . ✓ And 0.75 > 0.70 as forecast.
Worked example Example 6 — Cell F: how long will this SSD live?
A 512 GB drive uses TLC cells rated 1500 P/E cycles . The host writes 80 GB/day . GC runs at u = 0.60 . Estimate the lifetime in years.
Forecast: Big drive, moderate write load — guess: a few years?
Step 1 — WAF. WAF = 1 − 0.60 1 = 0.40 1 = 2.5 .
Why this step? We need to convert host writes into real flash writes; WAF is that conversion factor.
Step 2 — Total endurance. 512 GB × 1500 = 768 , 000 GB of physical writes possible.
Why this step? Every GB of cell can be programmed 1500 times before wearing out.
Step 3 — Daily physical wear. 80 GB/day × 2.5 = 200 GB/day actually written.
Why this step? The host's 80 GB becomes 200 GB after amplification.
Step 4 — Divide. 200 768 , 000 = 3840 days = 365 3840 ≈ 10.5 years .
Why this step? Total endurance ÷ daily consumption = number of days; divide by 365 for years.
Verify (units): GB/day GB = days . ✓ Numeric: 200 × 3840 = 768 , 000 . ✓ About a decade — sensible for a lightly-loaded consumer drive.
Worked example Example 7 — Cell G: buy years by adding spare space
Take the drive from Example 6 (u = 0.60 , lifetime 10.5 yr). Adding over-provisioning lets GC wait for emptier blocks, dropping u to 0.40 . By what factor does lifetime improve, and what is the new lifetime?
Forecast: Lower u means lower WAF means longer life — but how much ?
Step 1 — New WAF. WAF new = 1 − 0.40 1 = 0.60 1 = 1.667 .
Why this step? Emptier victim blocks copy less valid data.
Step 2 — Lifetime scales as 1/ WAF . Improvement = WAF new WAF old = 1.667 2.5 = 1.5 × .
Why this step? Endurance and daily host writes are unchanged, so only the WAF ratio matters.
Step 3 — New lifetime. 10.5 yr × 1.5 = 15.75 years .
Why this step? Multiply the old lifetime by the improvement factor.
Verify: Recompute from scratch: daily physical = 80 × 1.667 = 133.3 GB; 768 , 000/133.3 = 5760 days = 15.78 yr. ✓ Rounding-consistent with 15.75 .
Intuition Why the gain is so large for so little space
On the s01 curve, dropping u from 0.6 to 0.4 slides you down the steepening part of the graph. A small u change can be a big WAF change — that is the whole business case for reserving spare capacity.
Worked example Example 8 — Cell H: uneven wear when static leveling is off
A 100-block drive holds a movie on 80 cold blocks (never rewritten) and cycles all writes through the 20 free blocks . The host performs enough writes to erase 10{,}000 blocks-worth of data over the drive's life. With dynamic-only leveling, how many erases land on each hot block, and is that survivable at a 3000 P/E rating?
Forecast: 10{,}000 erases spread over only 20 blocks… that sounds like a lot each.
Step 1 — Blocks actually sharing the load. Only the 20 free blocks rotate; the 80 cold ones are frozen.
Why this step? Dynamic leveling only touches blocks it is actively writing — the parent's exact definition.
Step 2 — Erases per hot block. 20 10 , 000 = 500 erases each.
Why this step? Total erase work divided evenly over the blocks that share it.
Step 3 — Compare to rating. 500 < 3000 ? Yes — but check the ideal : if all 100 blocks shared, each would see 100 10 , 000 = 100 erases. Dynamic-only makes hot blocks age 100 500 = 5 × faster.
Why this step? The danger is relative — static leveling would give every block the same 100.
Step 4 — Push to failure. If the workload were 5 × heavier (50 , 000 erases), hot blocks hit 50 , 000/20 = 2500 while cold blocks sit at 0 — the drive is 2500/3000 = 83% dead on 20 blocks with 80 blocks pristine.
Why this step? This is the exact "movie you never touch" failure the parent warned about, now with numbers.
Verify: Total erases conserved: 20 × 500 = 10 , 000 ✓ (dynamic) and 100 × 100 = 10 , 000 ✓ (static-ideal). Same total work, wildly different peak wear — that is why static leveling exists.
Worked example Example 9 — Cell I: can a drive write
less than the host asked?
A controller with transparent compression takes a 1000 MB stream that compresses to 400 MB , then runs GC at u = 0.5 on the compressed data. What is the effective WAF seen from the host?
Forecast: GC alone gives 1/ ( 1 − 0.5 ) = 2 . But compression shrank the data first — could the two effects cancel, or even go below 1?
Step 1 — Physical writes from GC on compressed data. Compressed size = 400 MB; GC multiplies by 1 − 0.5 1 = 2 , giving 400 × 2 = 800 MB physically written.
Why this step? Amplification acts on the stored (compressed) bytes, not the original stream.
Step 2 — Effective WAF vs the host. host requested physical = 1000 800 = 0.8 .
Why this step? WAF is always physical-flash-bytes over host-requested-bytes; the host asked for 1000 MB.
Step 3 — Interpret. 0.8 < 1 : the drive wrote less to flash than the host handed it. The GC formula's floor of 1 is not violated — compression is a separate mechanism layered on top , exactly as the parent's mistake box explained.
Why this step? Reconciles the "WAF ≥ 1 from GC" rule with the sub-1 result.
Verify: Without compression, host = 1000 MB, physical = 1000 × 2 = 2000 , WAF = 2 . Compression cut physical to 800 , dividing WAF by 2000/800 = 2.5 : 2/2.5 = 0.8 . ✓
Common mistake "WAF < 1 breaks the
1/ ( 1 − u ) formula."
Why it feels right: 1/ ( 1 − u ) ≥ 1 always, so how can WAF drop below it?
The fix: 1/ ( 1 − u ) is the amplification of garbage collection only . Compression and dedup (SSD Architecture features) reduce bytes before GC ever sees them, so the effective end-to-end WAF can fall below 1.
Recall Self-check questions
WAF when victim blocks are 80% valid ::: 1/ ( 1 − 0.8 ) = 5
Physical meaning of u = 1 giving WAF = ∞ ::: GC copies every page and frees none — a forbidden, useless erase
Given WAF = 2 , what is u ? ::: u = 1 − 1/2 = 0.5
Why does dynamic-only leveling let hot blocks die 5× early in Ex 8? ::: writes rotate over only 20 of 100 blocks; static leveling would share all 100
How can end-to-end WAF be 0.8 despite GC? ::: transparent compression shrinks data before GC, lowering physical bytes below host bytes