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.

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.