TRIM and Garbage Collection: When SSD Data Is Permanently Gone

Deleting a file on an SSD triggers a three-step chain. The operating system removes the file from its directory, sends a TRIM command to the SSD controller, and the controller queues those blocks for garbage collection. Each step moves the data closer to permanent destruction.

1. OS deletion. The file system (NTFS, APFS, ext4) removes the file's directory entry. The file's logical block addresses are marked as free in the file system metadata. At this point, the data still exists on the NAND.
2. TRIM command sent. The OS sends a TRIM command (DATA SET MANAGEMENT for SATA, DEALLOCATE for NVMe) to the SSD controller. This tells the controller which logical addresses no longer contain valid data. TRIM does not erase anything; it informs the controller that it can erase those blocks when ready.
3. Garbage collection erases the NAND. The controller's background process reads valid pages out of mixed blocks, copies them to clean blocks, and applies an erase voltage to the old blocks. The erase voltage resets every cell in the block to its unprogrammed state. The data is physically gone.

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.

Modern SSDs implement DZAT (Deterministic Read Zero After TRIM). After the controller processes a TRIM command, it returns all zeroes for any read to those addresses, even if the physical NAND cells still hold the original data. Recovery software reads through the controller's standard interface, receives zeroes, and reports the files as unrecoverable.

DZAT (Deterministic Read Zero After TRIM)

SATA specification behavior. The controller intercepts all read commands to TRIMmed logical block addresses and returns a payload of all zeroes. Enforced at the firmware level before the read reaches the physical NAND. Most modern SATA SSDs implement DZAT.

DLFEAT=001b (NVMe Deallocate Features)

The NVMe equivalent of DZAT. When set in the namespace metadata, reads to deallocated blocks return all zeroes. Most modern NVMe controllers enforce this for predictable latency and RAID parity consistency.

DRAT (Deterministic Read After TRIM)

Older, less strict implementation. The controller returns a consistent value for TRIMmed addresses, but that value isn't guaranteed to be zeroes. Rarely seen in drives manufactured after 2018.

DZAT is the reason recovery software fails on modern SSDs. The controller lies to the operating system. It reports empty space where data may still physically exist on the NAND. This isn't a software bug. It's a protocol-level design decision built into the drive's firmware.

All modern SSDs implement deterministic post-TRIM behavior (DZAT on SATA, DLFEAT on NVMe), but the aggressiveness of garbage collection varies by controller family. Samsung controllers erase TRIMmed blocks within seconds. Silicon Motion controllers may defer GC for hours on a lightly used drive.

DZAT (SATA) and DLFEAT (NVMe) hide the data from software immediately. GC destroys it physically. Both happen automatically. The only variable is how fast GC runs after TRIM, and that depends on the controller, the drive's free space, and how long the drive stays powered on.

NAND flash stores data as charge trapped in a floating gate transistor. The floating gate sits between the control gate and the silicon channel, electrically isolated by thin oxide layers. Programming (writing data) uses hot-carrier injection or Fowler-Nordheim tunneling to push electrons onto the floating gate. Erasing uses Fowler-Nordheim tunneling in the reverse direction to pull electrons off.

Page-Level Writes, Block-Level Erases

NAND can write individual pages (4KB-16KB) but can only erase entire blocks (typically 256KB-4MB containing 64-256 pages). This asymmetry is why garbage collection exists. The controller can't erase a single deleted file's pages without erasing every page in that block. GC reads the still-valid pages out of a mixed block, copies them to a clean block, then erases the entire old block at once.

Erase Voltage and Fowler-Nordheim Tunneling

During block erasure, the controller applies 15-20V to the substrate while grounding the control gate. This voltage differential creates an electric field across the tunnel oxide that pulls electrons off the floating gate through quantum mechanical tunneling. The process takes 3-10 milliseconds per block and resets every cell in the block to the erased threshold voltage.

For SLC NAND, the erased state is a single threshold: 0xFF. For TLC NAND, which stores 3 bits per cell across 8 voltage levels, the erase resets all cells to the lowest threshold. For QLC (4 bits, 16 levels), the same principle applies but with tighter voltage margins. After erasure, there is no intermediate charge state that preserves the original data. The floating gate is either charged or discharged. An erased cell carries no recoverable information about what it previously stored.

Why Partial Erasure Doesn't Help

If power is lost mid-erase, some cells in the block may be partially drained while others retain their original charge. PC-3000 SSD can read pages from partially erased blocks and recover data from cells where the charge state is still above the read threshold. But this only applies to interrupted GC operations. A completed block erase is total. Every floating gate in the block has been fully discharged.

The Flash Translation Layer (FTL) is the controller's internal database that maps logical block addresses (what the OS sees) to physical NAND locations (where data is stored on the chips). When TRIM invalidates a logical address, the FTL updates its mapping to reflect that the physical block is a candidate for erasure.

PC-3000 SSD reads the FTL directly from the controller's DRAM cache or from NAND-backed metadata pages. The FTL contains three categories of entries that matter for TRIM recovery:

• Active mappings. Logical addresses pointing to physical pages with valid data. These are not affected by TRIM.
• Invalid mappings (TRIMmed, pending GC). Logical addresses where the FTL records that TRIM was received but GC has not yet erased the physical block. The data is still on the NAND. This is the recovery target.
• Free/erased blocks. Physical blocks that GC has already erased. The cells read as 0xFF. The data is permanently gone.

The ratio of “TRIMmed but not erased” blocks to “already erased” blocks determines how much of the deleted data can be recovered. A drive that lost power shortly after deletion will have most TRIMmed blocks still intact. A drive that ran for hours in idle will have most blocks erased by GC.