DZAT and NAND Physics: Why TRIM Makes SSD Recovery Impossible

TRIM is a command your operating system sends to the SSD after you delete a file. It tells the controller which data blocks are no longer needed. The controller then schedules those blocks for erasure during garbage collection. This two-step process is why recovery software shows zeroes on your SSD within seconds of deletion, even though the physical memory chips may still hold data.

On a hard drive, deleting a file only removes a pointer. The magnetic data on the platter sits there until something new overwrites it. SSDs work differently. The controller actively erases old data in the background to keep fresh blocks available for future writes. That background process is garbage collection, and it runs on its own schedule.

TRIM is enabled by default on Windows 7+ and macOS 10.6.8+. If you deleted files from an SSD connected to a modern operating system, TRIM almost certainly ran. The question isn't whether TRIM ran; it's whether garbage collection has finished erasing the NAND cells. That's what our free SSD evaluation determines.

Recovery is possible when the NAND cells still hold their original electrical charge. DZAT hides the data from software, but the physical memory chips don't know the difference. Between the moment TRIM runs and the moment garbage collection applies the erase voltage, a narrow recovery window exists. How long that window lasts depends on the controller.

Power off the SSD immediately after accidental deletion. Don't run recovery software; it triggers controller activity that can start GC. Ship the drive powered off to our Austin, TX lab. We'll check the raw NAND state for free. If GC has already erased the target blocks, we tell you and return the drive at no cost. For the full diagnostic path across queued-TRIM failures, OP-block survival, and firmware-crash scenarios, see our SSD data recovery service. SATA recovery starts at $200; NVMe starts at $200.

SATA SSD recovery ranges from $200–$1,500. NVMe SSD recovery ranges from $200–$2,500. Price depends on the failure type. If we determine that garbage collection has already erased your data, the evaluation costs nothing. +$100 rush fee to move to the front of the queue. No diagnostic fees. 4.9 stars across 1837+ Google reviews.

Circuit board repair (SATA: $450–$600, NVMe: $600–$900) involves component-level microsoldering to revive the original controller. This tier preserves the AES-256 encryption key, which is why it's the primary recovery path for modern encrypted SSDs. NAND swap (SATA: $1,200–$1,500, NVMe: $1,200–$2,500) requires a 50% deposit and is reserved for cases where the original PCB is too damaged for repair. A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.

Every modern SSD controller family we recover implements deterministic post-TRIM behavior, but the aggressiveness of garbage collection varies by controller firmware. Samsung controllers erase TRIMmed blocks within seconds of idle. Silicon Motion controllers defer GC until free block counts drop below a firmware-defined threshold. This timing difference determines how large the recovery window is for any given drive.

Silicon Motion controllers (SM2258XT, SM2259XT, SM2262EN, SM2263XT) offer the largest recovery window for post-TRIM data. Their “lazy GC” strategy preserves TRIMmed pages on lightly-used drives until the free block pool drops below a firmware-defined threshold. Samsung Elpis and Pascal controllers offer the smallest window; their GC begins within seconds of the drive going idle. We see this pattern consistently on our PC-3000 SSD diagnostic bench.

PS3110, SM2258XT, and Samsung MEX/MGX: DZAT Firmware Behavior in Detail

Three controller families dominate the SATA SSD installed base and define what recovery looks like in practice. The Phison PS3110-S10 is an 8-channel quad-core SATA controller with onboard DRAM, shipped on PNY CS1311, Patriot Ignite, and Mushkin Striker drives, plus extensive Toshiba and Lite-On rebranding. The PS3110 advertises Word 69 bit 5 set and processes TRIM through the DATA SET MANAGEMENT opcode 0x06 path. GC runs in batched bursts during idle: the firmware selects candidate blocks by invalid-page ratio, copies surviving valid pages forward, then applies the +15-20V erase pulse. PC-3000 forces the PS3110 into Safe Mode by shorting designated ROM/Safe Mode test points on the PCB while cycling power, halting GC mid-batch and exposing the pre-erase NAND state.

Silicon Motion SM2258XT is the DRAM-less budget controller behind the Crucial BX500, ADATA SU650, Kingston A400, WD Green, and a long tail of OEM-rebranded drives. Because the SM2258XT has no onboard DRAM, the entire FTL lives in NAND flash, so every metadata flush costs a NAND program cycle and firmware batches both flushes and erases against an internal idle watermark. The same architectural choice makes SM2258XT firmware more prone to service-area corruption after sudden power loss because the L2P delta sitting in SRAM is lost on power-down. PC-3000 enters Safe Mode by shorting the designated ROM pins on the PCB during power-on, bypassing the corrupted on-NAND firmware, and uploads an SRAM-only loader that reads physical pages without triggering the deferred GC.

Samsung MEX (840 EVO), MGX (850 EVO), and MJX (860 EVO) are the consumer SATA controllers behind Samsung's 8xx EVO line. All three advertise DZAT through Word 69 bit 5. GC on MEX and MGX is among the most aggressive of any SATA controller family we work with: idle-detect kicks in shortly after the last host command, and recovery windows on a powered-on Samsung 840/850/860 EVO drive are tight enough that running consumer recovery software can close the window before a scan completes. PC-3000 Samsung forces the controller into Techno Mode by shorting ROM pins on the PCB, then issues vendor commands to read raw NAND past the FTL. Separately, the Linux libata kernel still blacklists queued TRIM on the Samsung 8xx EVO family today; that blacklist is host-side mitigation for a firmware bug, not a recovery workflow, but it is a useful reminder that this controller family's TRIM pipeline has a documented failure history. The downstream consequence of this controller-by-controller GC timing variance is detailed in our analysis of the garbage collection data loss mechanism.

TRIM is not a single command. On SATA drives it is the DATA SET MANAGEMENT command (opcode 0x06) with the TRIM bit set in the feature register. On NVMe it is the Dataset Management command (opcode 0x09) with the Deallocate (AD) attribute. Both carry a payload of LBA ranges that the controller marks as invalid in the Flash Translation Layer. DZAT is the behavior enforced after those ranges are processed: any subsequent read to a deallocated LBA returns a deterministic zero payload sourced from the controller, not from NAND.

The sequence from host delete to physical NAND erase unfolds in four discrete steps, and the data is recoverable at every step except the last:

1. Host TRIM/DSM Deallocate issued. The OS sends DATA SET MANAGEMENT (SATA opcode 0x06) or Dataset Management with AD=1 (NVMe opcode 0x09) carrying the LBA range list. The NAND cells still hold the original programmed threshold voltages at this instant.
2. FTL marks the LBA range invalid. The controller writes a journal entry, updates the in-DRAM L2P table, and flushes the invalidated mapping to the NAND metadata region. DZAT/DLFEAT enforcement activates immediately; any subsequent host read to that LBA returns a zero payload fabricated by the controller, not fetched from NAND.
3. Block enters the GC candidate pool. The physical block backing those LBAs is queued for garbage collection, but no erase voltage has been applied. On Silicon Motion lazy-GC firmware the block can sit in the candidate pool for hours on a lightly used drive; on Samsung Elpis and Pascal firmware the candidate pool is drained within seconds of the drive going idle.
4. GC applies the +15-20V erase pulse. Reverse Fowler-Nordheim tunneling drains the charge storage layer across every cell in the block simultaneously. After this step the data is physically destroyed and no lab procedure recovers it. PC-3000 SSD's Safe Mode raw-NAND read path bypasses the DZAT mask at step 2 or 3; once step 4 completes, the cells read 0xFF at the physical level and the window is closed.

SATA: DATA SET MANAGEMENT (0x06) with TRIM

The host sends a DATA SET MANAGEMENT command with the TRIM feature bit (bit 0 of the feature field) set. The data transferred is a 512-byte LBA Range Entry block: up to 64 entries per block, each 8 bytes, encoding a 48-bit starting LBA and a 16-bit sector count. The SATA 3.1 specification added Queued TRIM, which uses the SEND FPDMA QUEUED command (opcode 0x64) with a DSM subcommand rather than the non-queued DATA SET MANAGEMENT opcode 0x06, allowing TRIM to execute concurrently with other queued I/O. Word 69 bit 5 of the IDENTIFY DEVICE response advertises DZAT support; bit 14 advertises DRAT. If both bits are zero, the drive predates deterministic post-TRIM behavior, and stale data may be returned on reads to deallocated LBAs.

NVMe: Dataset Management (0x09) with Deallocate

The NVMe equivalent is the Dataset Management command (opcode 0x09). The host sets the AD (Attribute - Deallocate) bit in CDW11 and transfers a range list encoded as 16-byte entries (starting LBA, length, context attributes). Post-deallocate read behavior is controlled by the DLFEAT byte (byte offset 33 of the Identify Namespace data structure). Bits 2:0 of DLFEAT define the behavior: 000b means no guarantee on returned values; 001b returns all zeroes (DZAT-equivalent); 010b returns all ones. Every mainstream consumer and enterprise NVMe SSD manufactured after 2019 reports DLFEAT=001b.

Flag Table Zero Return Versus NAND Erase Block Cycle Timing

The DZAT zero return is not produced by reading a NAND page that has been wiped. It is produced by the controller checking a per-LBA invalid bit in the FTL flag table and, on a hit, synthesizing an all-zero buffer in DRAM and returning it to the host. That flag-table lookup completes in microseconds. The host receives a zero payload before the SATA or NVMe completion frame would have had time to round-trip a real NAND page read, which is why software-only recovery tools cannot distinguish a freshly TRIMmed block from a block whose cells have been fully drained: the bytes coming back over the wire look identical because both are fabricated by the controller, not fetched from silicon.

The actual NAND erase block cycle is on a different time scale entirely. The block must be selected by the GC scheduler, the surviving valid pages must be relocated, the charge pump must ramp the +15-20V erase pulse onto the P-well, the pulse must hold long enough for reverse Fowler-Nordheim tunneling to drain the charge storage layer, and an erase-verify pass must confirm every cell read at the 0xFF threshold before the block is returned to the free pool. Foreground GC under host pressure pushes that sequence through quickly; background GC on a lightly loaded drive can defer it. Between the flag-table lookup that fakes the zero return and the verified erase that actually drains the cells, the NAND still carries its original programmed threshold voltages. PC-3000 SSD's Safe Mode reads land inside that gap, which is the entire reason a lab-level solid state drive data recovery workflow can return data that consumer software has already declared gone.

Queued TRIM Bugs and the Survival Window

Queued TRIM implementations have shipped with firmware bugs that extend the recovery window. The Linux kernel's libata subsystem maintains an explicit blacklist (ATA_HORKAGE_NO_NCQ_TRIM) for Samsung 840 Pro, 850 Pro, and 860 Pro drives on older firmware, as well as certain Micron M500/M510/M550 models, because queued TRIM on those drives can corrupt the FTL. On a blacklisted drive, queued TRIMs may be dropped silently or processed out of order, leaving mapped LBAs whose NAND pages still hold the original charge state. PC-3000 SSD's Safe Mode read of physical NAND exposes this residue even though the standard read path still returns DZAT zeroes.

Power-Off Before the Erase Voltage

DZAT masking is a controller-side response, not a NAND-side change. At the moment TRIM is processed, the FTL entry is invalidated and the block is enqueued for garbage collection, but the NAND cells still carry the original programmed threshold voltages. The physical erase happens later, when GC applies +15-20V through the P-well and reverse Fowler-Nordheim tunneling drains the charge layer. If the drive loses power between TRIM invalidation and GC erase, the data survives. Continued power cycles without executing background tasks also accumulate wear that eventually becomes relevant to the NAND degradation failure mode, where retention loss itself becomes the obstacle rather than TRIM.

Over-Provisioned and Retired Blocks

The ATA DATA SET MANAGEMENT protocol operates only on LBAs the host can address. Over-provisioned blocks, spare blocks used for bad-block replacement, and retired blocks fenced by the controller are invisible to TRIM. Stale page copies relocated during wear leveling frequently survive in these controller-managed regions. When board-level repair or in-system PC-3000 access is not feasible, the final path for reading these regions is chip-off NAND recovery, where the NAND packages are desoldered and read on a dedicated hardware programmer. Chip-off yields useful plaintext only on unencrypted controllers; on AES-256 encrypted SSDs the harvested data is ciphertext without the controller-bound key.

For the full diagnostic and pricing path across SATA and NVMe failure modes, see the flagship SSD data recovery service.

TRIM is advisory. The ATA/ATAPI Command Set spec (ACS-4, INCITS 529-2018) defines DATA SET MANAGEMENT with the TRIM bit as a hint that lets the controller schedule garbage collection at its own discretion. It makes no promise about when the NAND cells are physically erased, only that subsequent reads to deallocated LBAs will return the deterministic payload specified by RZAT or DRAT. The entire recovery window examined on this page is a direct consequence of that scheduling freedom.

Word 169 bit 0 vs Word 69 bits 5 and 14

ACS-4 splits TRIM-related IDENTIFY DEVICE reporting across two words. Word 169 bit 0 advertises that the device supports DATA SET MANAGEMENT with the TRIM feature set at all. Word 69 bits 5 and 14 describe the post-deallocation read guarantee: RZAT (bit 5) when the controller must return zeroes, DRAT (bit 14) when it must return a deterministic but non-zero pattern. A drive that reports Word 169 bit 0 set but Word 69 bits 5 and 14 cleared still accepts TRIM commands; it simply does not guarantee what a subsequent read will see, which on a few pre-2015 SATA SSDs left stale NAND contents addressable through the standard read path until GC completed.

SANITIZE BLOCK ERASE Guarantees Physical Erasure

The SANITIZE feature set (ACS-3 and later) uses a single opcode, SANITIZE DEVICE (B4h), with the subcommand selected through the ATA Feature register: BLOCK ERASE EXT (feature 12h), CRYPTO SCRAMBLE EXT (feature 11h), and OVERWRITE EXT (feature 14h). Unlike TRIM, SANITIZE BLOCK ERASE EXT is contractually required to apply the NAND erase voltage to every user-addressable and over-provisioned block before reporting completion. The command runs as a long operation, not a queued one, and the device must report progress through SANITIZE STATUS EXT (00h) until erasure finishes. If SANITIZE was issued and completed, physical recovery is gone across the entire NAND array, including OP blocks the host cannot reach. TRIM, by contrast, operates only on host-visible LBAs and never promises physical erase. This is why a customer who ran TRIM may still have recoverable data while a customer who ran SANITIZE BLOCK ERASE does not. CRYPTO SCRAMBLE EXT on a hardware-encrypted drive simply rotates the Media Encryption Key, which renders the existing NAND contents ciphertext-without-key in microseconds.

NVMe Range-Count and Range-Size Ceilings (DMRL and DMRSL)

The NVMe Base Specification (rev 2.0) places explicit ceilings on Dataset Management payloads through two fields in the I/O Command Set Specific Identify Controller data structure for the NVM Command Set (CNS 05h). DMRL (Dataset Management Ranges Limit) is the maximum number of 16-byte range entries a single DSM command may carry; DMRSL (Dataset Management Range Size Limit) is the maximum logical block count a single range may describe. When the host needs to deallocate a region larger than DMRSL or wider than DMRL, the operating system splits the operation into multiple DSM commands. Each split increases the number of moments at which a power loss or controller crash can land between range commits, which is why large delete operations on NVMe produce more partial-unmap residue than small ones.

Over-Provisioning Free-Block-Pool GC Trigger Thresholds

The duration of the survival window in the over-provisioned area is governed by the controller's free-block-pool management. A consumer SSD with 7% factory OP maintains a pool of clean erased blocks that the controller refills by compacting and erasing stale blocks during idle time. Firmware defines a low-water mark (the free-block count at which foreground GC begins blocking writes) and a high-water mark (the free-block count at which background GC stops). A TRIMmed block enters the candidate pool immediately, but whether it is erased next depends on its wear count, how many valid pages it still holds, and where the free pool currently sits relative to those thresholds. On a lightly used drive sitting near the high-water mark, a TRIMmed block with a low wear count and few valid pages may remain intact for hours on Silicon Motion SM2258XT or SM2262EN firmware. On a near-full drive approaching the low-water mark, that same block is erased within seconds because foreground GC is actively hunting candidates to keep host writes flowing.

Enterprise SSDs with 28% OP (e.g., 800GB usable from 1024GB raw) extend this window further because the pool of candidate blocks is deeper. Consumer drives with minimal OP (2-7%) have the shortest window because any deallocation is likely to be needed to keep the free pool above the low-water mark. This is why identical deletes on two drives of the same model but different fill levels produce different outcomes when the drive arrives in our lab.

Mid-Unmap FTL Journal Orphaning

A TRIM or DSM Deallocate is not atomic at the NAND level. The controller first writes a journal entry to a reserved metadata region recording the intent to invalidate a set of L2P mappings, then updates the in-DRAM L2P table, then flushes the updated L2P page to NAND, then eventually erases the backing blocks. Power loss or a firmware exception between any two of those steps leaves a specific residue signature. A crash after journal write but before L2P flush leaves the old L2P mapping valid on the next boot; the original NAND pages are still pointed at by valid logical addresses. A crash after L2P flush but before erase leaves the L2P marked invalid but the NAND still programmed. PC-3000 SSD's Safe Mode scans both the current FTL and the journal region, then reads the physical pages those orphaned mappings reference. Queued-TRIM firmware bugs on the blacklisted Samsung and Micron models referenced above are a specific sub-case of this orphaning: the journal records one LBA range, the FTL commits a different range, and the disagreement strands deallocated pages that the host still sees as valid. This is why power loss or a crash mid-unmap is a favorable arrival condition and why running recovery software on a suspect drive can resolve those orphans by triggering a clean journal replay.

Chip-off via a dedicated NAND programmer remains the final option when the controller is dead and no Safe Mode entry is available. Chip-off yields plaintext only on unencrypted controllers; on AES-256 encrypted SSDs the harvested dump is ciphertext without the controller-bound key. SATA chip-off recovery runs $1,200–$1,500; NVMe chip-off runs $1,200–$2,500. A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.

Many modern SSDs encrypt data automatically using AES-256 hardware encryption, though budget and mid-range drives (WD SN770, Crucial P3, older Phison PS3111-S11 designs) omit this feature. On encrypted drives, the Media Encryption Key is bound to the controller hardware. If the controller dies, the NAND chips contain only ciphertext. Desoldering the NAND and reading it on another controller (chip-off) yields encrypted data with no key. Board-level repair to revive the original controller is the only recovery path for encrypted SSDs.

NVMe SSDs implementing TCG Opal or IEEE 1667 bind the AES-256 key material to the controller's hardware fuses. A dead Phison PS5012-E12 on a Sabrent Rocket means the NAND contents are unreadable without the original controller's key. A dead Samsung Elpis on a 980 Pro means the same thing. Chip-off on an encrypted NVMe drive is not a recovery option; it's an expensive way to get a dump of ciphertext.

Most data recovery labs outsource board-level failures or declare them unrecoverable. We locate the failed component using FLIR thermal imaging, replace the shorted PMIC or voltage regulator with a Hakko FM-2032 on an FM-203 base station, and bring the original controller back to life. When the controller boots, the encryption keys are intact and the data is accessible. Board repair isn't a separate service from data recovery; for encrypted SSDs, it is the recovery. Circuit board repair runs $450–$600 for SATA SSDs, $600–$900 for NVMe.

Academic research has measured approximately 0.5V threshold voltage variance between NAND cells that were erased after storing data and cells that were never programmed. This variance is a measurable physical artifact of the programming and erasure process. It is not commercially recoverable. No data recovery lab, including ours, can extract usable data from this residual voltage difference using SSD controllers or PC-3000 SSD.

The 0.5V variance is detectable with semiconductor characterization equipment (probe stations, source-measure units) operated at the die level. This equipment costs six figures, operates on decapped NAND dies, and produces raw analog measurements that require statistical analysis to interpret. The distinction between “erased after storing a 1” and “erased after storing a 0” is a probability distribution, not a clean binary signal.

For TLC and QLC NAND with 8 or 16 voltage levels respectively, the margins between legitimate states are already tight (as narrow as 200mV for QLC). A 0.5V residual variance doesn't provide enough signal-to-noise ratio to reconstruct multi-bit cell states with any confidence. If a company claims they can recover data from physically erased NAND cells, they are either describing a different failure scenario (GC interrupted before completing) or describing a capability that doesn't exist commercially.