SSD Garbage Collection and Data Loss

SSD garbage collection (GC) is an automated background process run by the SSD's internal controller. It consolidates valid data from fragmented NAND blocks into clean blocks, then physically erases the old blocks so they can accept new writes. GC is the step that permanently destroys deleted data on an SSD.

When you delete a file, the operating system sends a TRIM command to the SSD. TRIM marks the file's logical addresses as invalid in the controller's Flash Translation Layer (FTL). TRIM does not erase anything. The controller queues those blocks for garbage collection, which runs during idle time and applies the erase voltage that resets the NAND cells to their unprogrammed state.

This two-step process is what makes SSD data recovery different from hard drive recovery. On a hard drive, deleted files stay on the magnetic platters until new data overwrites the same sectors. On an SSD, the controller actively hunts for stale blocks and erases them in the background, regardless of whether new data needs that space.

Recovery software operates at the logical layer above the SSD controller. It sends standard read commands through the OS storage driver. When the controller has DZAT enabled, every read to a TRIMmed block returns zeroes. The software sees empty space and reports the data as unrecoverable.

Tools like Disk Drill, EaseUS, Recuva, and R-Studio all operate at the top two layers. They cannot bypass the controller's DZAT enforcement, and they cannot access raw NAND pages below the FTL. When these tools report zero recoverable files from a TRIMmed SSD, the data may still exist physically on the NAND. It requires hardware that communicates with the controller at the diagnostic level, not through the standard storage protocol.

The time between a file deletion and a successful PC-3000 SSD read depends on two things: what the host sent to the drive (the ATA or NVMe command payload) and what the controller decides to do with the over-provisioned NAND pool. Both layers are specified by JEDEC and the T13 ACS-4 standard, and both behave differently across controller families.

ATA DATA SET MANAGEMENT: the Command That Carries TRIM

TRIM is a feature of the DATA SET MANAGEMENT command (opcode 0x06), introduced in ACS-2 and refined in ACS-4. The host sets the Trim bit in the Count register, then transmits a buffer of LBA Range Entries. Each entry is an 8-byte structure: a 6-byte starting LBA followed by a 2-byte range length. Entries are packed into 512-byte sectors; a single command can carry up to 64 sectors, or 4,096 ranges per transfer. The controller queues those ranges into the FTL, walks the logical-to-physical map, and marks every matching page invalid. No NAND cell is touched by this command. The block-level ERASE that actually destroys the data is a separate, later step, run by garbage collection at the controller's discretion.

The NVMe equivalent is the Dataset Management command (opcode 09h) with the Deallocate attribute, defined in NVM Express 2.0. The namespace's DLFEAT field in Identify Namespace tells the host what the drive will return on a subsequent read to a deallocated LBA. DLFEAT bit values determine whether the drive guarantees zeros, guarantees a fixed deterministic value, or makes no guarantee at all.

Deterministic vs Non-Deterministic TRIM Return Behavior

Not every SSD enforces DZAT. The SATA spec allows three distinct behaviors for reads to TRIMmed LBAs, and an enterprise NVMe drive can advertise a fourth through DLFEAT. A drive that returns data non-deterministically can leak plaintext through the standard read path for a limited window; a drive that enforces DZAT cannot. Both states sit above the NAND itself; neither tells you whether the underlying cells have been physically erased.

None of these modes describe what has happened at the NAND layer. They only describe what the controller returns on the host interface. PC-3000 SSD operates below this interface entirely, which is why DZAT enforcement does not block a lab recovery when the physical cells still hold charge.

How Over-Provisioning Preserves Invalidated Pages Across P/E Cycles

The recovery window is not a stopwatch. It is a count of program/erase cycles on other blocks between the moment TRIM ran and the moment wear-leveling scheduled the original block for erase. Over-provisioning is the reserve pool that gives the controller somewhere else to write while leaving invalidated pages in place.

Consumer SSDs typically allocate 7% of raw NAND to OP; mixed-workload enterprise drives allocate 20% to 28% (documented in JEDEC JESD218 and vendor datasheets). When OP is high, the controller has ample clean blocks to absorb host writes and can defer both GC and wear-leveling across thousands of write transactions. An invalidated page can survive until the controller's static wear-leveling sweep picks its block for refresh, which on lightly used drives happens once per thousands of P/E cycles on other blocks. This is why powering the drive off immediately halts the clock: with no host writes arriving, no OP pressure accumulates, no background sweep runs, and the invalidated pages stay programmed.

Conversely, a drive written near capacity operates with an OP that behaves like zero. Every new host write forces the controller to reclaim a block immediately. Under this pressure, foreground GC erases TRIMmed blocks within seconds, and the recovery window closes before the drive can be shipped.

PC-3000 SSD FTL Translator Snapshot Extraction

When a deletion event has already run but the NAND has not yet been erased, raw physical reads return the programmed cell states. They do not return files. A modern SSD scatters a single file across hundreds of physical pages on different dies, indexed only by the FTL translator. To turn raw NAND pages back into files, the lab must rebuild the translator as it existed before the deletion.

Controllers store copies of the FTL translator in the NAND service area as a power-loss recovery safeguard. Every time the translator updates, the controller commits a new generation to service-area logs and retires the oldest. The number of retained generations is controller-specific: Silicon Motion SM2259XT drives carry multi-generation translator backups in the service area; Phison E12 and E18 use a rolling journal; Samsung firmware commits a checkpointed translator on shutdown and between wear-leveling passes.

After PC-3000 SSD enters the controller's diagnostic mode, Data Extractor walks the service area, parses every retained translator generation, and presents them as rollback points. The engineer picks a generation dated before the deletion event. Data Extractor re-applies that translator on top of the raw NAND image; pages the current FTL marks invalid resolve against the older translator and reassemble as live files. The recovery is not a scan for file headers; it is a forensic rollback of the mapping table.

Two conditions determine whether this works. The target blocks must not have been erased by GC since the deletion (so the physical pages still hold data). The service-area translator log must contain at least one generation dated before the deletion event (so there is a rollback point to restore). Drives shipped powered off within hours of a deletion event typically satisfy both conditions.

Retention Physics Bound the Powered-Off Recovery Window

Powering the drive off stops garbage collection, but it does not stop charge loss. An invalidated NAND page is still a programmed page; its electrons sit on a floating gate behind a tunnel oxide that has been stressed by every prior P/E cycle on that block. JEDEC JESD218 specifies the minimum retention the manufacturer must guarantee at End of Life: a client-class SSD must hold data for 1 year powered off at 30C, an enterprise-class SSD for 3 months powered off at 40C. Both numbers are floors at full P/E exhaustion, not steady-state behavior.

The Arrhenius rule governs the temperature dependence; retention roughly halves for every 5C to 10C rise in ambient. A drive shipped in a hot vehicle or stored on a warm shelf loses its window faster than the JEDEC floor suggests. Two physical mechanisms drive the decay on worn drives. Stress-Induced Leakage Current (SILC) is a weak steady leakage through trap sites in the tunnel oxide. Trap-Assisted Tunneling (TAT) is the more aggressive failure mode: trap sites align into a conductive path and electrons hop out of the floating gate orders of magnitude faster than through pristine oxide. A fresh drive can hold an invalidated page for years; a drive late in its rated P/E budget can drop below the LDPC correction threshold in months.

Cell geometry compounds the problem. TLC partitions the cell voltage window into 8 Vt states; QLC partitions the same window into 16. The narrower QLC margins overlap under far less charge loss, so the powered-off recovery window on a QLC drive closes earlier than on TLC at equivalent wear. The controller's background refresh routine does not save these pages either; refresh scans skip pages the FTL has marked invalid, so retention loss on TRIMmed cells is never scrubbed. The practical implication for a customer is direct: ship the drive promptly and keep it cool. A drive sitting in a desk drawer at room temperature for a few days loses far less margin than the same drive baking in a vehicle cabin for the same period.

NAND flash cannot overwrite data in place. The SSD must erase an entire block (128 to 256 pages, typically 256KB to 4MB) before writing new data to any page within that block. Garbage collection exists to prepare erased blocks for future writes by reclaiming blocks that contain a mix of valid and invalid pages.

Page-Level Writes, Block-Level Erases

Pages (4KB to 16KB) are the smallest unit the controller can read or write. Blocks (groups of 128 to 256 pages) are the smallest unit the controller can erase. When the OS modifies a file, the controller writes updated data to a new, clean page and marks the old page as invalid in the FTL. This out-of-place write model means blocks gradually accumulate invalid pages alongside valid ones.

The GC Cycle

1. Identification: The controller selects a block with a high ratio of invalid pages. Controllers track valid/invalid ratios for every block on the drive.
2. Valid page migration: The controller reads the remaining valid pages from the target block and writes them to a clean, pre-erased block.
3. Block erase: The controller applies erase voltage to the entire target block, resetting all cells (both previously valid and invalid) to the unprogrammed state (0xFF). This step permanently destroys the deleted data.

Background GC vs. Foreground GC

Background GC runs during idle periods without interrupting host I/O. The controller uses dedicated processing cores (Phison controllers use "CoX processors" for this) to clean blocks quietly. Foreground GC triggers when the pool of free blocks drops too low to handle incoming writes. The controller pauses host operations to erase blocks in real time, causing the latency spikes known as the "performance cliff." From a recovery perspective, foreground GC is the worst scenario: it erases TRIMmed blocks immediately to free space for new data.

Over-Provisioning and GC Timing

Over-provisioning (OP) is a reserve of NAND blocks hidden from the user. A drive with 10% OP always has a buffer of free blocks available for writes while background GC processes dirty blocks at its own pace. More OP means the controller can defer physical erasure for longer periods. A nearly full drive with minimal free space triggers aggressive foreground GC, erasing stale blocks within seconds of a TRIM command. Enterprise SSDs with 28% or more OP tend to have the most relaxed GC scheduling; consumer drives with 7% OP erase more aggressively.

The gap between TRIM marking blocks as invalid and GC physically erasing those blocks is the only recovery window. Powering off the SSD immediately after data loss freezes the controller state and prevents GC from running.

1. Power off the drive immediately. Disconnect the SSD from the system. Do not shut down the OS normally if you can avoid it; a normal shutdown gives the controller idle time to run GC before power is removed.
2. Do not reconnect to a running OS. Plugging the SSD back into a running system sends queued TRIM commands and gives the controller idle time to resume GC. Even mounting the drive as read-only may trigger controller activity.
3. Do not run recovery software. Consumer recovery tools send read commands through the standard interface. On a DZAT drive, these reads return zeroes (giving you no useful data). Worse, the drive is powered on and idle between read commands, allowing background GC to execute.
4. Ship the drive powered off to a lab with PC-3000 SSD. The PC-3000 forces the controller into a diagnostic state that disables all background processes, including GC, before reading raw NAND.

If the SSD suffered a power loss or firmware failure before GC ran, the data is likely intact on the NAND. Firmware failures freeze the controller mid-operation, preventing all background tasks including GC. Drives stuck in safe mode (SATAFIRM S11, BSY state, 0-byte capacity) have not run GC since the failure occurred.

The host operating system addresses an SSD by Logical Block Address (LBA), a flat numeric index that looks like a sector on a magnetic platter. The NAND chips underneath are organized by Physical Block Address (PBA): die, plane, block, page. The Flash Translation Layer is the lookup table that turns one into the other. The entire question of post-deletion recovery comes down to what that table looks like at three specific moments: before TRIM, immediately after TRIM, and after the erase cycle completes.

GC Queue Depth, Over-Provisioning, and Write Amplification

The GC queue is not a single FIFO; it is a multi-priority structure the controller walks every time it needs a free block. Each candidate block carries an internal score driven by its ratio of invalid pages to valid pages, its program/erase count relative to neighbor blocks (the wear-leveling input), and whether it sits in the user-visible region or in the over-provisioning reserve. A high-OP drive maintains queue depth in the thousands of blocks, which lets the controller pick a block with the highest invalid-page ratio every time. That choice minimizes the number of valid pages that must be migrated per reclaimed block, which directly suppresses write amplification.

Over-provisioning, wear leveling, and write-amplification factor (WAF) are connected through this queue. JEDEC JESD218 defines WAF as the ratio of NAND writes to host writes; every valid-page migration adds to the numerator without changing the denominator. Higher OP raises queue depth, which lowers the average migrations per reclaim, which lowers WAF, which lowers the rate at which fresh blocks must be reclaimed. The same loop governs the recovery window: with more free blocks in reserve, the controller can leave the block containing the invalidated pages at the bottom of the priority list across many host writes. Powering the drive off freezes the entire queue, regardless of where the source block sat.

A near-full drive inverts the picture. With OP behaving as zero, queue depth collapses to whatever blocks the controller can recycle on demand. Every host write forces the controller to pull the next candidate, migrate its valid pages, and erase the source. WAF climbs, free-block reserve stays at the floor, and the source block holding the deleted file moves to the head of the queue within seconds. This is the worst-case starting condition for any SSD recovery attempt.

Consumer recovery software (Disk Drill, EaseUS, Recuva, R-Studio, DMDE, UFS Explorer in its standard scanning mode, PhotoRec) works by issuing standard READ commands through the operating system's block layer. The OS hands those reads to the AHCI or NVMe driver, the driver pushes them onto the drive's command queue, and the controller responds. On any SSD with DZAT or DLFEAT bits 2:0 = 001b, every one of those reads to a TRIMmed LBA returns zeros from the controller firmware. The software sees a flat field of zeros and reports the data as unrecoverable. The result is the same whether the NAND still holds the original charge states or whether GC erased the block ten seconds ago. None of these tools can see past the controller's synthesized zero buffer.

The tools are not broken. They are doing exactly what their architecture allows. They read what the controller hands them. On a healthy drive with TRIM disabled and a logical-only failure (accidental delete on a system that never sent TRIM, a corrupted partition table, a botched file system check), R-Studio and DMDE can still produce results because the FTL never unmapped the LBAs and the controller still serves the original NAND contents. That is a logical recovery scenario, not a post-TRIM scenario. The moment TRIM runs and the drive enforces DZAT, the software-only path is closed. Recovery moves to TRIM-aware lab procedures that bypass the controller's standard interface, either through PC-3000 SSD diagnostic-mode entry or through chip-off NAND extraction when the controller is dead and chip-off is viable for the controller family (which excludes encrypted modern NVMe drives whose AES-256 key lives in controller silicon).