SSD Garbage Collection

Garbage collection on an SSD is the controller’s housekeeping process: it identifies blocks of NAND flash that contain a mix of still-valid pages and stale pages, copies the valid pages somewhere else, and then erases the original blocks to make them available for new writes. Without garbage collection, the SSD would eventually exhaust its supply of pre-erased blocks and grind to a halt; with garbage collection, the drive maintains a steady supply of empty blocks ready for incoming writes.¹

The Seagate “messy room” analogy

The Seagate SSD documentation captures the concept accessibly: “In simple terms, garbage collection is like cleaning up a messy room. It sorts through the items (data blocks), keeps what you need, and throws away the junk (unused data). This keeps the SSD organized and running smoothly.” The analogy understates the complexity (what GC actually does is more like rebuilding a partially-occupied storage shelf into completely empty and completely full sections) but captures the essential purpose: reclaiming partially-used space into completely-free space.

The fundamental purpose

The DataRecovery.com garbage collection documentation captures the design goal: “The goal of garbage collection is to keep as many empty blocks as possible, so that when the SSD needs to write data, it can do so without waiting for a block to be erased.”² Block erasure takes time (milliseconds, much longer than writes); if the SSD has to erase a block before every write, performance collapses. By erasing blocks ahead of time during quiet periods, garbage collection ensures the SSD has empty blocks ready when the host needs to write.

When garbage collection runs

Garbage collection runs in two distinct modes:

• Background GC (idle-time): the controller opportunistically reclaims blocks during periods when the host isn’t issuing read or write commands. This is the preferred mode because it doesn’t affect user-visible performance.
• Foreground GC (active): when the supply of pre-erased blocks runs low and the host is still issuing writes, GC runs urgently in the foreground while user writes are happening. This causes the famous SSD slowdown pattern when drives become full.

Modern controllers tune their GC aggressiveness to balance performance impact against the risk of running out of pre-erased blocks. Enterprise drives often have larger reserved areas and more aggressive GC; consumer drives optimize for typical bursty workloads where idle-time GC handles most cleanup.

The performance and endurance trade-off

Garbage collection is essential, but it has costs. Every GC operation involves reading valid pages, writing them to new locations, and erasing source blocks; each of these operations consumes NAND endurance. The metric called write amplification factor (WAF) measures how many physical writes happen for each logical write the host requests; aggressive GC produces high WAF, which accelerates wear. Modern controllers minimize unnecessary GC and use sophisticated algorithms to choose the most-efficient blocks for reclamation.

SSDs need garbage collection because of two architectural constraints in NAND flash. Without GC, neither constraint could be reconciled with normal storage usage patterns; with GC, the SSD presents a clean abstraction to the host while handling the complexity internally.³

The “no in-place modification” rule

NAND flash has a fundamental architectural quirk: writes can only flip bits in one direction (1 to 0). Flipping a bit back from 0 to 1 requires erasing the entire block containing that cell. This means SSDs cannot modify data in place the way HDDs do; when the operating system updates a logical block, the SSD has to write the new data to a fresh location and mark the old location as stale.

The block-level erase constraint

The TechTarget garbage collection documentation captures the granularity mismatch: “Flash SSDs divide storage into blocks, which are further divided into pages. Data is read and written at the page level but must be erased at the block level. A significant amount of voltage is needed to erase data, and it is difficult to target that voltage at a more granular level without negatively impacting adjacent cells.” A typical NAND block is several megabytes containing hundreds of pages of 4-16 KB each. The SSD can read or write any page individually but can only erase entire blocks; this asymmetry is the fundamental reason garbage collection has to exist.

The accumulated stale data problem

The SSD Review garbage collection primer captures the consequence: “Data can be written directly into an empty page, but only whole blocks can be erased. Therefore, to reclaim the space taken up by invalid data, all the valid data from one block must be first copied and written into the empty pages of a new block.” Over time, blocks naturally end up with a mix of valid pages (still containing useful data) and stale pages (data that’s been logically deleted or overwritten elsewhere). Without intervention, the SSD would slowly fill up with these mixed blocks and run out of completely-empty blocks for new writes.

Comparison to HDD behavior

The Rossmann Group SSD recovery documentation captures the contrast: “On a magnetic hard drive, deleting a file only removes the directory pointer. The magnetic orientation on the media stays until new data writes over the same physical location. The data waits to be overwritten.” HDDs don’t need garbage collection because they can overwrite any sector at any time without preparation; the magnetic media accepts new data directly. SSDs can’t, so they have to actively manage the stale-data problem through GC. The architectural difference is the root cause of the recovery difference: HDD deletion leaves data on the disk until overwritten, while SSD deletion leads to active erasure once GC runs.

Without garbage collection

If garbage collection were disabled or failed:

• Each write would require erasing a block first, slowing writes by 10x or more.
• Every update to existing data would consume one entire block of writes, accelerating wear dramatically.
• The drive would eventually have all blocks marked as containing some stale data and no completely-empty blocks for new writes; the drive would refuse new writes despite having “free space” in the file system.
• Performance would be roughly equivalent to early-2000s flash storage; modern SSD speeds depend entirely on having pre-erased blocks ready for writes.

The garbage collection process involves three distinct phases: identifying which blocks to reclaim, preserving the still-valid data from those blocks, and physically erasing the blocks. Each phase has subtleties that affect performance, endurance, and recovery prospects.⁴

Phase 1: Block selection

The controller has to choose which block to reclaim next. Common selection algorithms:

• Greedy (most common): select the block with the highest proportion of stale pages (lowest valid page count). This minimizes the work of preserving valid data.
• Quick clean (USPTO 8,166,233): if a block has zero valid pages (everything in it is stale), erase it immediately without any copying. This is the cheapest case.
• Deep clean (USPTO 8,166,233): when no zero-valid blocks exist, compact N partially-valid blocks down to M free blocks by consolidating their valid pages.
• Age-aware: consider how recently the block was written; very recent writes might be modified again soon and shouldn’t be moved yet.
• Wear-aware: consider the block’s program/erase cycle count; blocks that have been erased fewer times should be preferred for reclamation to support wear leveling.

Phase 2: Valid page preservation

The USPTO patent 8,799,561 valid-page-threshold-based GC documentation describes this step: “Any valid pages (i.e., pages containing data that has not been overwritten) residing in the victim block are copied to another memory block, and the victim block is erased.” The controller has to:

1. Identify which pages in the source block are still valid (the FTL mapping table provides this).
2. Read those pages out of the source block.
3. Write them to fresh, pre-erased pages elsewhere.
4. Update the FTL mapping table so the affected logical addresses now point to the new physical locations.
5. Verify the writes completed successfully before proceeding.

Each valid page that has to be moved increases write amplification; blocks with very few valid pages are cheap to reclaim, while blocks with many valid pages are expensive. This is why greedy algorithms strongly prefer blocks that are mostly stale.

Phase 3: Block erasure

Once the valid pages have been safely moved, the controller can physically erase the original block. The Rossmann Group SSD documentation describes the physical mechanism: “When garbage collection erases a block, it applies a high voltage (15-20V) that drains every floating gate in the block through Fowler-Nordheim tunneling. The charge that represented your data no longer exists.” The erased block is added to the free block pool, ready for new writes.

The free block pool

Every SSD maintains a pool of pre-erased blocks ready to receive new writes. When the host issues a write, the controller pulls a block from the pool, writes the data, and updates the FTL. The size of this pool is critical to write performance; larger pools mean GC has more breathing room before becoming urgent. Over-provisioning contributes to this pool by setting aside reserved capacity that the host never sees but the controller can use for the free block pool.

GC algorithm sophistication

Beyond basic block selection, modern controllers implement increasingly sophisticated GC techniques. The USPTO patent 9,898,404 describes one example: “A garbage collection (GC) manager configured to recover storage space based on a predefined GC triggering events; and a de-dupe module coupled to the GC manager and configured to identify a duplicated page for a valid page within an erasable block based on signature comparison via a signature table.” Some controllers compress data during GC, deduplicate identical pages across blocks, and use machine learning to predict which blocks are best candidates for reclamation. The trend is toward GC that’s increasingly invisible to user-visible performance even under demanding workloads.

TRIM and garbage collection are different operations that work together. Understanding the relationship clarifies why both exist and what each does.⁵

What TRIM does

The Seagate TRIM documentation describes the mechanism: “When a file is deleted or overwritten on an SSD, the operating system sends a TRIM command to the SSD to indicate data in the specific blocks is not needed. Marking Blocks: The SSD controller then receives the TRIM command and marks these blocks as invalid or free. Instead of immediately erasing the data, the SSD just notes that these blocks can be used for new data in the future.” TRIM is a host-to-SSD signaling mechanism; it doesn’t actually erase anything itself. It just provides information that the SSD wouldn’t otherwise have.

What GC does that TRIM doesn’t

The ProStorage TRIM and GC documentation captures the distinction: “TRIM isn’t an alternative to garbage collection; it works with garbage collection to more properly mark pages as stale. And you don’t need TRIM for garbage collection to work, but TRIM makes an SSD’s garbage collection more efficient.” TRIM marks pages as stale; GC actually performs the physical erasure that frees the cells for reuse. The two operations are sequential: TRIM informs, GC executes.

The 3-step deletion chain

The Rossmann Group documentation describes the full deletion sequence on a TRIM-enabled SSD:

1. File system deletion: the OS removes the directory entry for the file. From the file system’s perspective, the file is gone.
2. TRIM mark: the OS issues TRIM commands to the SSD telling it which logical blocks are now free. The SSD updates its FTL mapping to mark those blocks as stale.
3. Garbage collection erase: the SSD’s GC eventually selects blocks containing stale pages, copies any remaining valid pages elsewhere, and physically erases the source blocks.

The Rossmann Group documentation captures the recovery implication directly: “The gap between step 2 and step 3 is the only recovery window. If the drive loses power, suffers a firmware crash, or stays busy with other I/O before GC runs, the data may survive on the physical NAND. Once GC applies the erase voltage, no recovery method exists.”

Without TRIM: GC works less efficiently

Older systems and some embedded environments don’t support TRIM. Without TRIM, the SSD has no way to know that user data has been logically deleted; the OS deletion is purely a file system change that the SSD never sees. The SSD has to assume all written pages might still be valid and copies them all forward during GC. This produces higher write amplification, lower performance, and faster wear, but doesn’t break the SSD; it just makes it less efficient. TRIM became standard on Windows 7+, modern Linux, and macOS for native Apple SSDs (with a manual enable for third-party SSDs on macOS).

TRIM and recovery are at odds

From a recovery perspective, TRIM and GC together represent a substantially less recovery-friendly environment than HDDs. On HDDs, deleted file recovery typically works because the magnetic data persists until overwritten by new writes to the same physical sector. On TRIM-enabled SSDs, deleted data is actively erased by GC within minutes to hours of TRIM marking; recovery software that works perfectly on HDDs may find nothing on SSDs even when run immediately after deletion. This isn’t a flaw in the recovery software; it’s a fundamental architectural difference between the two storage types.

Garbage collection is the central reason that SSD recovery has different prospects and different urgency than HDD recovery. Understanding GC’s effect on recovery shapes practical recovery decisions.⁶

The “race against GC” reality

The Rossmann Group documentation captures the recovery time pressure: “If garbage collection hasn’t finished, the original charge states may still exist on the raw NAND. A free diagnostic on PC-3000 SSD determines which blocks survived.” The window between TRIM marking and GC erasure varies dramatically based on:

• Drive workload: a busy SSD’s GC runs aggressively; an idle SSD’s GC may not get to a particular block for hours.
• Drive fullness: nearly-full SSDs run aggressive foreground GC; SSDs with substantial free space run lazier background GC.
• Block selection: blocks with many stale pages get reclaimed quickly; blocks with mostly-valid pages may persist much longer.
• Power events: GC interrupted by power loss may leave the affected block partially-erased or fully intact, depending on timing.
• Firmware version: different controllers have different GC aggressiveness profiles.

The practical implication: SSD recovery becomes time-critical the moment data is deleted. Continued use of the drive accelerates GC and reduces the recovery window; powering off the drive immediately preserves the existing state.

Why “just plugging in the drive” makes recovery harder

The same Rossmann Group documentation describes a counter-intuitive risk: even just connecting a struggling SSD to a working system can accelerate data loss. The OS attempts to mount the drive, replays journal entries from the file system, issues queued TRIM commands for files marked deleted but not yet TRIMmed, and the SSD’s GC begins reclamation in response. By the time the user thinks “I should run recovery software”, GC may have already erased the blocks containing the data they wanted to recover.

What survives GC

Some data on SSDs survives despite GC. Examples:

• Data in still-valid pages of mixed blocks: the entire block hasn’t been GC’d because some pages are still valid; the stale pages within the block may persist for hours or days until GC reaches them.
• Pre-TRIM-era deleted data: data deleted before TRIM was enabled may still be on the drive in pages the controller doesn’t know are stale.
• Power-loss-interrupted GC: if power is lost during the move-valid-pages phase but before erasure, the original block remains intact.
• Failed-controller drives: if the controller has failed, GC has stopped running; whatever was on the NAND at the time of failure remains.
• Over-provisioning area: data in the OP area may persist longer because OP blocks are managed differently from user-visible blocks.

Diagnosing GC survival with PC-3000

Professional recovery labs use specialized tools to determine what survived GC on a particular drive. PC-3000 SSD can read raw NAND content (after firmware-level recovery or chip-off) and identify which blocks contain data versus which have been erased by GC. The diagnostic answers the practical question: is recovery possible at all, or has GC already erased the target data? A negative result (everything erased) means recovery is genuinely impossible; a positive result (data survives) means recovery work can proceed.

Implications for recovery decisions

The GC reality shapes practical SSD recovery guidance:

• Power off immediately on suspected data loss: stops GC from continuing, preserves current state.
• Don’t try to “test” the drive by mounting it again: mounting triggers journal replays and TRIM commands that accelerate GC.
• Don’t run consumer recovery software repeatedly: each scan attempt may trigger additional GC activity, especially if the software writes anything (logs, indexes, results).
• Get the drive to a professional service quickly: the time pressure is real and dramatically affects success rates.
• Use chip-off recovery as last resort: bypasses controller and GC entirely, reads NAND directly; can recover data even from drives where GC has been actively erasing.