Recovery methodsTechnical

TRIM, Deallocate and Garbage Collection

Deallocation and physical erasure are two separate events on flash storage — the controller can stop returning old data long before, or well after, the underlying NAND is actually overwritten.

Filesystem deletion starts the chain

Deleting a file at the filesystem level normally just changes metadata: it marks the space as free and removes the entry that said the file existed. Nothing about that step touches the underlying storage medium directly. What happens next depends on whether, and how, that freed space is communicated down to the device.

ATA TRIM and NVMe Deallocate are host-to-controller messages

For SATA devices this communication is the ATA Data Set Management command carrying a TRIM hint; for NVMe devices it is the Dataset Management command's Deallocate attribute, defined in the NVM Command Set specification along with granularity and alignment fields for how deallocation ranges are described. Either way, the message tells the controller that the previous contents of specific logical ranges no longer need to be preserved — it does not itself identify or erase one physical NAND page. What the controller does with that information afterward is entirely controller- and firmware-defined.

Propagation depends on the entire storage path, not just the SSD

A device supporting TRIM/deallocate is not proof that a particular deletion was actually trimmed. The command has to survive the filesystem, the operating system, the storage driver, the SATA/AHCI or NVMe stack, and — for external or layered storage — a USB bridge, UASP/SCSI translation, a RAID controller, a NAS, a hypervisor, or an encryption/volume layer. Any of these can silently absorb the hint without passing it further down. This is one of the most important practical facts in SSD deletion recovery: “the SSD supports TRIM” says nothing about whether this specific deletion was trimmed.

Read-after-deallocate is what ordinary recovery software actually sees

Once a logical range has been deallocated and the controller has updated its own bookkeeping, the host may no longer receive the previous contents through the normal logical interface — reads can return zeros or other deterministic, device-defined content. Recovery software working through the standard block interface only ever sees the controller's current logical response; if trimmed ranges already return zeros through that interface, ordinary undelete tools cannot bypass the controller by “scanning deeper” — there is nothing deeper available through that path.

Invalid pages are not the same as erased blocks

Deallocation changes what the controller is willing to expose logically. Garbage collection is the separate, later process that actually erases the underlying physical NAND: it identifies a block holding a mix of valid and invalid pages, copies the still-valid pages elsewhere, updates the mapping table, erases the original block, and returns it to the free-block pool. Between those two events, data marked invalid by deallocation can still physically exist on the NAND, even though the controller has already stopped returning it through ordinary reads.

Powered time can matter, but there is no universal countdown

Because garbage collection is a background, firmware-managed process, its timing depends on idle time, available free blocks, write workload, over-provisioning, thermal state, power state and the specific drive model. Claims like “TRIM erases data within 30 seconds” or “unplug immediately and chip-off will recover it” do not hold up as universal rules. The more defensible statement is that additional powered time can allow background maintenance to progress further, without any externally observable countdown predicting the physical fate of a particular trimmed range on a particular device.

Why chip-off does not automatically bypass TRIM

Physical remnants of deallocated data can genuinely still exist in NAND before garbage collection erases them, but turning that remanence into a usable file is a separate problem from finding it. It generally still requires identifying which pages belong to which logical generation, undoing any scrambling, correcting ECC, reconstructing the translation layer well enough to know which page is which, distinguishing stale copies from current ones, and rebuilding filesystem metadata on top of all of that. Physical remanence and practical recoverability are separate questions, and controller-level encryption tied to internal state can make even a perfectly preserved stale page cryptographically inaccessible without the right key material.

USB flash without host TRIM still manages flash internally

A USB flash drive can still perform FTL translation, wear leveling, bad-block remapping, garbage collection and internal copying even when the host never sends it ATA or NVMe deallocate semantics at all — the controller firmware manages the flash regardless. USB and SSD recovery therefore share most of the raw-NAND reconstruction concepts above, but SSD-specific TRIM-propagation assumptions do not automatically transfer to a USB stick.

Practical rule

Establish what the logical interface actually returns for the affected range before assuming physical remnants are usable — and before assuming they are already gone.