Technology card
ShippingGarbage Collection in Flash Storage
Flash GC · SSD garbage collection
How flash reclaims blocks, why copying reduces the net space gain, and what TRIM and background cleaning do not guarantee.
Glossary entry on hesela.dev · JSON record
Related
On this page6 sections
In one minute
Flash garbage collection preserves a victim erase block's still-valid data elsewhere before erasing that block for reuse.
NAND updates do not simply overwrite the old physical page. A controller can place the new version elsewhere, leaving an obsolete page behind. Before reusing an erase block, it preserves any remaining current pages in other space and erases the victim. An invalid page is therefore not yet an independently reusable erased page. [2]
Reclamation needs headroom: the live data has to fit somewhere before its source block is erased. Selecting a victim with fewer live pages reduces copying for that cleaning event. Spare capacity and placement affect the available choices, but no single free-space percentage guarantees a particular latency. [1]
GC is not necessarily an idle-time job. Kingston describes specific SandForce-based SSDs using foreground collection without background collection. That is a documented implementation choice, not proof that foreground cleaning always wins. Scheduling decides when work competes with requests; it does not remove the work. [2]
TRIM supplies information that selected logical ranges are no longer needed. When the stack conveys and honors that information, a collector can avoid preserving their old contents. The notification does not require immediate physical erasure. Free space reported by a filesystem and erased space available inside a device are different observations. [3]
Nor is an apparently empty logical range evidence of secure removal. Wei and colleagues distinguish host-visible addresses from physical flash copies and warn that TRIM is not a reliable security guarantee. Their 2011 device measurements are historical evidence, not recovery rates for current SSDs. [4]
Garbage collection and wear leveling have different objectives: recover reusable space versus distribute wear. A policy that repeatedly chooses easy-to-clean hot blocks can leave cold blocks comparatively untouched. Efficient reclamation does not by itself demonstrate balanced wear. [1]
The accounting below is Hesela's hypothetical example, not a device benchmark. Assume one fully programmed block of N equal-sized pages, V still valid. Each valid page is copied once into already-erased destination space, then the victim is successfully erased. Ignore metadata, parity, failures and all other traffic.
Erasure makes N victim pages free, but relocation consumed V free destination pages. The net gain is N - V pages. Copying work per net reclaimed page is V / (N - V), defined only for V < N. This denominator is reclaimed space, not host writes: the ratio is not whole-device write amplification.
With no valid pages, no live-page copy is needed, although erasure still is. With all pages valid, moving them and erasing the victim gives zero net free-space gain in this model. That boundary helps explain why counting erased blocks alone cannot measure useful reclamation.
When comparing implementations, record workload, fill history, discard delivery, spare capacity and whether reported counters represent host writes, physical programming or only copies. Copyback can change the transfer path without making relocation equivalent to zero physical writes; the linked analysis examines that separate boundary.
Reclaimed space and copying
All rows use a hypothetical eight-page full victim. Copy each live page once; exclude metadata, parity and failures. Fractions are exact. No latency, endurance or device-wide WAF is inferred.
Local reclamation accounting, not measured SSD write amplification
- 0 of 8
- Copies / net free pages0 copied / 8 gained
- Copies per net reclaimed page0
- 2 of 8
- Copies / net free pages2 copied / 6 gained
- Copies per net reclaimed page1/3
- 6 of 8
- Copies / net free pages6 copied / 2 gained
- Copies per net reclaimed page3
- 8 of 8
- Copies / net free pages8 copied / 0 gained
- Copies per net reclaimed pageUndefined: zero net gain
Uncertainty notes
- Source-backed mechanism overview plus explicit bookkeeping assumptions; no new hardware experiment or measured performance claim.
- Agrawal et al. evaluate historical trace-driven simulations. Kingston describes particular controller-based products, not all current SSDs.
Sources
- 01Agrawal et al. Design Tradeoffs for SSD Performance. USENIX ATC 2008, sections 3.2, 3.3 and 5. · accessed 2026-11-10
- 02Kingston. Garbage Collection Methodologies for Greater SSD Performance for Client Workloads. SandForce-specific scheduling example. · accessed 2026-11-10
- 03Everpure Microsoft Platform Guide. TRIM: logical invalidation versus physical erasure. · accessed 2026-11-10
- 04Wei, Grupp, Spada and Swanson. Reliably Erasing Data From Flash-Based Solid State Drives. USENIX FAST 2011, sections 2.2 and 3.3. · accessed 2026-11-10