Erasing a block of flash means holding more than twenty volts across the cells for three and a half milliseconds, a duration the manufacturer fixed at design time to cover the worst chip in the worst condition — and measuring 160 real chips shows that most blocks are fully erased well before that, so the extra time is pure damage to the cells and pure delay to whoever is waiting; this paper (POSTECH, Kyungpook and ETH Zurich) predicts how long each erase actually needs from a count the chip already computes for its own purposes, extending drive lifetime by 43 percent and cutting the worst read latencies by a third, with no change to the flash chips at all.
The argument in one glance
-
Problem
Erasing is what wears the drive out and what makes reads wait
A flash cell stores data as trapped charge, and both writing and erasing move that charge with high voltage, which damages the cell a little each time. Erasing does most of the damage — around 80 percent of the total stress — not because its voltage is higher but because it is applied for roughly ten times as long. That same duration is the reason a read arriving behind an erase can wait several milliseconds when it would normally take forty microseconds.
-
What people did
Fix the duration at design time, generously
The manufacturer picks one erase duration for the whole product and burns it in. It must be long enough to fully erase the most stubborn block on the worst chip under the worst operating conditions, because an incompletely erased block cannot be written correctly. On top of that, the drive retries with a progressively higher voltage if a block still is not clean, which is what makes the scheme safe as cells age.
-
Why it fell short
One duration for cells that are not alike
Flash cells vary enormously because of manufacturing, and how hard a block is to erase also depends on how much it has already been used. A single worst-case number is therefore far too long for almost every block almost all the time. Characterising 160 real chips shows that 79 to 90 percent of blocks could be completely and reliably erased 17 to 29 percent faster than the fixed setting — meaning most of the wear and most of the waiting were never necessary.
-
This paper's idea
Ask each block how long it needs, using a number already counted
This paper (Sungjun Cho, Beomjun Kim, Hyunuk Cho, Gyeongseob Seo, Onur Mutlu, Myungsuk Kim and Jisung Park) predicts the duration each block actually needs from the number of cells still not erased after a pulse — a count the chip computes anyway to decide whether to retry. Two refinements follow: begin every erase with a short probing pulse so the count always exists, and spend some of the drive's error-correction headroom to cut the duration further.
Why this problem is worth solving
The operation being tuned is stranger than a read or a write, so it is worth describing.
A
flash cell holds data as charge, and erasing means pulling that charge out by applying a
high voltage — over twenty volts — to the substrate. This can only be done to a whole block
at once, thousands of pages together, which is why erase latency is measured in milliseconds
while a read takes tens of microseconds. Because cells differ, one pulse may not clean them
all, so the standard scheme is a loop. Apply the erase voltage for a fixed time, then do a
verify read that senses the whole block at once and counts how many cells still hold too
much charge — the FAIL BITS. If that count is below a threshold the block is clean and the
operation ends; otherwise the voltage is raised a step and another pulse is applied. Each
iteration costs the full fixed pulse duration plus about a hundred microseconds of verifying.
On the chips measured here, every erase needs at least two of these loops once a block has
been used two thousand times, and sometimes five.
The aggressive version of the idea spends a resource that sounds alarming to spend.
EVERY
drive corrects raw bit errors with a code strong enough to fix several tens of errors per
kilobyte, and that strength is chosen for the worst case the drive must survive — a fully
worn block holding data for a year at temperature. A fresh block is nowhere near that, so
most of the correction capability sits unused for most of the drive’s life. There is also a
second backstop underneath it: when errors exceed what the code can fix, the drive re-reads
the page with a different reference voltage until they come down. So the paper permits
erasing a block slightly incompletely, accepting the extra errors that leaves, on three
arguments — the unused margin is largest exactly when blocks are young, the reduced erase
stress means fewer errors later, and under the data scrambling every drive already performs
about seven eighths of the incompletely erased cells will be written to a higher charge state
anyway, where their residual charge does not matter.
What people did before, and where it broke
-
Suspend or reschedule the erase. A long line of work reduces the damage erases do to latency by pausing an erase when a read arrives, or by scheduling erases when the drive is idle. This is the standard answer and it is effective.
-
The gap. It moves the erase without making it shorter. The cell stress is unchanged, so drive lifetime is untouched, and a suspended erase must still finish eventually.
-
Lower the erase voltage. One family reduces stress by using a gentler voltage, which narrows the voltage window available for the programmed states.
-
The gap. The narrower window has to be paid for by programming more precisely, which makes writes slower. It also stops applying once blocks are worn past a few thousand cycles, and it does not shorten the erase.
-
Skip the early loops. Another approach tracks how many loops a block needed last time and jumps straight to the final, highest voltage, skipping the ones that were going to fail.
-
The gap. On the 3D chips measured here it backfires. Cells are harder to erase than in the older technology it was designed for, so it frequently guesses wrong, incurs erase failures, and ends up applying more stress — measured at 25 percent shorter lifetime than doing nothing.
-
Predict from the cycle count. Erase difficulty correlates with how many times a block has been programmed and erased, so that count is the obvious predictor.
-
The gap. It is not enough. Manufacturing variation means blocks at the same cycle count need visibly different durations, so a prediction from the count alone must be conservative for the same reason the manufacturer’s number was.
How each erase learns its own duration
One erase operation under an adaptive scheme
-
-
new
-
new
-
new
-
new
-
new
The idea
The chip was already measuring what it needed to predict. The obstacle to shortening an erase is that you cannot know in advance how long a particular block needs, and the natural predictor — how many times the block has been cycled — is too coarse, because manufacturing variation makes blocks at the same age need visibly different durations. The insight is that a far better signal is already being computed and thrown away. After every pulse the chip performs a verify read that counts the cells not yet erased, because that count is how the loop decides whether to stop. That number is a direct measurement of how far this block currently is from clean, so it predicts how much more pulse is required. Using it costs nothing in the chip and requires no change to it. Finding the useful signal inside data a device already produces for its own purposes is the same move as the flash-mapping work covered elsewhere on this site, which makes an approximate address table safe by leaning on verification metadata the medium already carried.
A short first pulse to buy information. The prediction has an obvious hole — the first pulse has no predecessor, so there is no count to predict from, and the first pulse is exactly where the fixed duration is spent most often. The fix is to begin with a deliberately short pulse, about a millisecond, that will usually not finish the job, then verify to obtain the count, then apply a remainder pulse sized from it. What was a single blind three-and-a-half millisecond pulse becomes a probe plus a measured remainder, which for the majority of blocks totals substantially less. The characterisation shows this is well behaved — blocks falling in the nth fail-bit range after the probe are completely erased by a remainder of half a millisecond times n. Reading the manufacturer’s conservative fixed setting as a measurement problem rather than a constant is the same argument as the read-retry work covered elsewhere on this site, which measured commercial chips exhaustively and found the vendor’s built-in table close to arbitrary.
Spending a margin that was provisioned for a worse day. The conservative version stops where reliability is unchanged. The aggressive version goes further by relaxing the threshold at which a block counts as erased, accepting some cells left slightly charged and the extra read errors that follow. Three things make that defensible. The error-correction code is sized for a fully worn block holding data for a year, so its unused capability is largest exactly when blocks are young and this is being exploited. Reducing erase stress slows the growth of errors, so the trade partly pays for itself over the drive’s life — the measurements show a higher starting error rate but a much flatter curve, which is what actually determines when a block becomes unusable. And under the data scrambling drives already apply, roughly seven eighths of the incompletely erased cells will be programmed to a higher charge state anyway, where their leftover charge is irrelevant. Deliberately consuming headroom that was provisioned for a worst case that rarely arrives, with a measured bound on the risk, is exactly the argument of the datacenter power work covered elsewhere on this site.
Erasing one block the adaptive way
What happens during a single adaptive erase
Following one block from the decision to erase it through to a verified clean state.
Step 1 of 5
Apply a short probing pulse
Rather than the full 3.5 milliseconds, the controller configures a pulse of about 1 millisecond at the normal starting voltage. For most blocks this removes most of the charge but leaves some cells above the threshold.
This is deliberately an incomplete operation. Its purpose is to reach a state that can be measured, since the prediction that follows needs a fail-bit count and the very first pulse of an erase has no earlier count to draw on.
Why it works
- The predictor is a measurement, not a proxy. Using the count of cells still unerased after a pulse → the signal reflects this block’s condition right now rather than its age → it captures the manufacturing variation that makes blocks of equal age need different durations, which the cycle count cannot.
- The signal is free. The verify read and its fail-bit counter exist to decide whether to retry → obtaining the number requires no new circuitry and no change to the flash chip → the whole scheme lives in the controller and configures pulse duration through a command that already exists.
- A short first pulse converts a blind operation into a measured one. Probing for a millisecond and then sizing the remainder → the first loop, where the fixed duration was most often spent in full, becomes adaptive too → single-loop erases benefit, which is most erases on a young drive.
- Less stress now means fewer errors later. Shortening every pulse reduces the damage each erase inflicts → the error rate grows more slowly with use → blocks meet the reliability requirement out to 7,600 cycles instead of 5,300, which is where the 43 percent comes from.
- Correction headroom is largest exactly when it is being spent. The code is sized for a worn block after a year of retention → a young block has enormous unused capability → the aggressive variant can afford incomplete erasure precisely in the regime where it is applied most.
What it costs (trade-offs and scope)
- Fresh blocks start out noticeably dirtier. The aggressive variant raises the raw error rate of new blocks substantially, trading a worse starting point for a much flatter curve. That is only a good trade if the flat curve holds, which the characterisation supports but which depends on the reliability model being right.
- It consumes a safety margin. The error-correction capability being spent was provisioned for worst-case conditions. Spending it means less is left for anything else that goes wrong, and the benefit shrinks directly with how much margin a given drive design leaves.
- Average performance barely moves. Erases are rare compared to reads and writes, so the average latency and throughput numbers are essentially unchanged. The gains are in worst-case latency and in lifetime, which is the honest framing the paper uses.
- The tables are per-device-family. The mapping from fail-bit counts to durations comes from characterising real chips, so a manufacturer or a drive vendor must do that measurement for each design. The authors argue their chips are representative but cannot show it.
- Performance is simulated. Reliability and lifetime rest on 160 real chips, which is the paper’s strength, but the latency results come from an SSD simulator with traces rather than from a drive.
The evaluation
| Property | What was measured | The result | What it tells you |
|---|---|---|---|
| How much slack the fixed duration leaves | |||
| Lifetime | |||
| Against prior techniques | |||
| Tail latency | |||
| What it costs to build |
Check yourself
Check your understanding
1. Why is the number of program and erase cycles a block has experienced an insufficient predictor of how long it needs to be erased?
2. What is the purpose of the deliberately short first pulse?
3. The aggressive variant allows blocks to be left slightly incompletely erased. Why is that defensible?
4. Predict why the tail-latency benefit shrinks as the drive wears, from 26 percent down to 13 percent.
Sources
AERO: Adaptive Erase Operation for Improving Lifetime and Performance of Modern NAND Flash-Based SSDs. Sungjun Cho, Beomjun Kim, Hyunuk Cho, Gyeongseob Seo, Onur Mutlu, Myungsuk Kim, Jisung Park. ASPLOS 2024, pages 101 to 118. DOI 10.1145/3620666.3651341. Full text read from the authors’ preprint, arXiv 2404.10355.