What TRIM Does and Why It Destroys Data

TRIM is an ATA command (DATA SET MANAGEMENT) that the operating system sends to an SSD controller to identify logical block addresses that are no longer in use. When you delete a file, the OS marks those blocks as free in its filesystem table and sends a TRIM command to the SSD. The controller then schedules those physical NAND blocks for erasure during garbage collection. Once erased, the data is physically gone from the NAND cells and cannot be recovered.

What TRIM Tells the Controller to Do

On a hard drive, deleting a file only removes the directory entry that points to the file's data. The actual data remains on the platters until another file overwrites those sectors. This is why hard drive data recovery software can scan for deleted files and often find them intact.

SSDs work differently because of how NAND flash writes. NAND can be written at the page level (typically 4-16 KB) but can only be erased at the block level (typically 256-512 pages per block). Writing to a page that already contains data requires erasing the entire block first, then rewriting all valid pages in the block plus the new data. This is called write amplification.

TRIM reduces write amplification by informing the controller which pages contain deleted data. The controller can then skip those pages during block consolidation, and the garbage collector can erase blocks that contain only invalidated pages without needing to copy any valid data out first.

Canonical TRIM Terminology

Data recovery work on flash storage runs into the same acronyms across SATA, NVMe, and SCSI stacks. The terms below are the exact names used in the ATA-8 ACS-4 and NVMe 2.0 specifications, and in the IDENTIFY DEVICE and IDENTIFY NAMESPACE structures that a PC-3000 or a kernel driver reads off the drive during enumeration.

ATA DATA SET MANAGEMENT (DSM), opcode 0x06

The SATA command that carries TRIM. The DSM feature field selects the sub-function; bit 0 enables the TRIM sub-function, which delivers a list of LBA ranges the host no longer uses. The controller is free to queue the work, reorder it, or ignore it.

NVMe DEALLOCATE (Dataset Management, opcode 0x09)

The NVMe equivalent of ATA DSM TRIM. The Dataset Management command with the Deallocate (AD) bit set in the Context Attributes field tells the controller that the listed LBA ranges can be released. Read behavior after deallocate is governed by the DLFEAT field in IDENTIFY NAMESPACE.

SCSI UNMAP (opcode 0x42)

The SCSI command used for the same purpose on SAS drives and on USB Attached SCSI (UAS) enclosures. When a USB-to-NVMe bridge chip claims to pass TRIM, what it is actually doing is translating UNMAP into NVMe DEALLOCATE on the back side of the bridge.

DRAT (Deterministic Read After Trim)

Reported in IDENTIFY DEVICE Word 169 bit 14. Guarantees that every read of a TRIMmed LBA returns the same value, but that value can be any constant, including stale data the controller chose to pin. Useful to recovery tools only when combined with knowledge of what value the firmware returns.

DZAT (Deterministic Read Zero After Trim)

Reported in IDENTIFY DEVICE Word 169 bit 5. Guarantees that reads of TRIMmed LBAs return all zeroes. This is the case on most modern consumer SATA SSDs, and is why recovery software run against a TRIMmed volume on a DZAT drive sees a sea of zeroes where the user data used to be.

Queued TRIM (SATA FPDMA Queued)

An optional extension that lets TRIM commands ride inside the Native Command Queuing (NCQ) pipeline instead of draining the queue first. Several early SATA SSDs implemented this incorrectly at the firmware level, and the Linux kernel maintains a blacklist that disables queued TRIM on known-bad drives.

Overprovisioning (OP)

Raw NAND capacity the controller reserves and never exposes as user LBAs. Works in concert with TRIM: the larger the OP pool, the more free erase blocks the garbage collector can consume without having to relocate valid data, which is why enterprise SSDs with 28% or higher OP sustain writes longer than consumer drives with 7% OP.

Garbage Collection: Deterministic vs Non-Deterministic

Garbage collection is the controller's background process of reclaiming blocks that contain a mix of valid and invalid (TRIMmed or overwritten) pages. The controller reads valid pages from partially used blocks, writes them to a new block, and erases the old block to make it available for new writes.

How the controller handles reads of TRIMmed blocks before garbage collection completes determines whether the TRIM implementation is deterministic or non-deterministic:

Most modern consumer SSDs implement deterministic TRIM. The practical effect is that once the OS sends the TRIM command, recovery software reading those LBAs will get zeroes, regardless of whether the physical NAND erase has completed yet.

Why TRIMmed Blocks Are Unrecoverable

When garbage collection erases a NAND block, it applies an erase voltage that pulls all trapped electrons out of the floating gates (or charge trap layers) in every cell in the block. Every cell returns to its erased state: all 1s in binary. The data that was stored in those cells no longer exists in any physical form.

This differs from hard drive deletion in a critical way. On an HDD, deleted data remains as magnetic polarity patterns until overwritten. On an SSD, TRIM-triggered garbage collection physically resets the cells. There are no residual charge patterns to read. Chip-off NAND extraction (desoldering the NAND chips and reading them directly) will show erased blocks where the data used to be.

TRIM Behavior Across Operating Systems

The USB enclosure exception matters for recovery. Many consumer SSDs used as external drives in USB enclosures never receive TRIM commands because the USB-SATA bridge chip does not support the TRIM passthrough. In these cases, deleted data may still be present on the NAND because the controller never received the instruction to erase it. This is one of the few scenarios where logical SSD recovery still has a real chance of returning user files.

NVMe USB Enclosures and SCSI UNMAP Passthrough

NVMe USB enclosures do not speak NVMe to the host. They present as SCSI devices over USB Attached SCSI (UAS), and the bridge IC is responsible for translating SCSI commands into NVMe admin and I/O commands on the SSD side. Whether TRIM reaches the NAND depends entirely on whether the bridge translates SCSI UNMAP into NVMe DEALLOCATE.

The Realtek RTL9210 and RTL9210B bridges implement SCSI-to-NVMe tunneling, forward UNMAP as DEALLOCATE, and generally behave like a proper NVMe device to the operating system. The older JMicron JMS583 does not reliably pass UNMAP, runs hot under sustained load, and drops off the USB bus during long imaging sessions, which makes it hostile to forensic cloning. The ASMedia ASM2362 falls between the two and varies by firmware revision.

For a working drive that a user has been putting files on through a USB-NVMe enclosure, the outcome depends on the specific bridge. A JMS583-based enclosure often preserves deleted data because DEALLOCATE never reaches the controller; an RTL9210-based enclosure behaves like direct NVMe and the data is gone the moment garbage collection runs.

Why Hardware RAID Controllers Disable TRIM

Enterprise hardware RAID controllers in RAID mode (LSI MegaRAID, Dell PERC H730P, H740P) typically refuse to forward TRIM commands to member SSDs. The reason is parity integrity. If a drive advertising DZAT receives a TRIM command and zeroes the referenced LBAs, the parity block the controller already computed across the stripe no longer matches the data blocks on disk. Subsequent reads will pass, but any rebuild or consistency check reads the zeroed blocks and either flags parity errors or overwrites valid data with parity-reconstructed zeroes.

The same physical controller flashed to IT mode (HBA passthrough) does forward TRIM, because in that mode the host owns the array layout (usually ZFS, mdadm, or Storage Spaces) and the firmware is not computing parity. Software RAID stacks that are TRIM-aware (Linux mdraid with RAID 1/10, ZFS, Btrfs RAID 1) propagate TRIM to the underlying devices once the array geometry and block offsets are understood.

This pattern is relevant during RAID recovery: a hardware-RAID SSD array presented to a recovery workstation usually still contains every user LBA on the NAND because the controller never issued TRIM. The controller's own metadata (DDF, PERC proprietary layout) has to be reconstructed first, but the underlying data has not been erased.

Samsung 860 and 870 EVO Queued TRIM Firmware Bug

The Samsung 860 EVO and 870 EVO SATA SSDs shipped with queued TRIM (FPDMA Queued) firmware that interacts badly with several AMD and Intel SATA controllers. The visible symptom in the Linux kernel log is a cascade of WRITE FPDMA QUEUED and SEND FPDMA QUEUED timeouts, followed by the drive being reset and remounted read-only. Left alone, this corrupts filesystems.

The kernel maintains a blacklist in libata-core.c that disables queued TRIM on Samsung 8xx-series SSDs. Administrators who hit the issue on older kernels can force the behavior with the boot parameter libata.force=noncqtrim, which allows NCQ for reads and writes while serializing TRIM. For recovery work, an 860/870 EVO that has been living through these lockups often contains a mix of completed and partially-completed TRIM ranges, because some queued TRIM commands were aborted mid-flight. The practical effect is an unusually high rate of stale versus zeroed blocks on that drive compared to a healthy SSD.

Frequently Asked Questions