What Is an SSD Controller & How Does TRIM Affect Your Data?

Summary: Deleting a file from an SSD does not automatically make it unrecoverable. What determines the outcome is not the deletion itself but what the drive’s controller does in the time that follows. Through processes such as TRIM and garbage collection — which run independently of user action — the controller progressively clears blocks that are no longer in use. How far that background work has progressed at the point of recovery determines what remains accessible and what has been permanently erased. This is why two data-loss cases that appear identical can end with different results. This article explains how that process works and what to consider before attempting a recovery.

A deleted file does not always disappear the way most people assume. On a hard drive, data stays exactly where it was on the platter until something new is written over it, which is why recovery, in that case, is largely a matter of acting before that overwrite occurs.

Solid-state drives complicate that picture considerably. Two SSDs holding the same type of deleted file can end up in entirely different states within minutes of each other, since SSD controllers run idle-time maintenance cycles, including TRIM processing and garbage collection, that can clear a deleted file’s NAND blocks well before the user notices anything is wrong. The cause lies inside the drive, in a component that runs its own routines independently of anything the user does.

What is an SSD Controller?

An SSD controller is the embedded processor responsible for every operation on the drive, including communication between the host computer and the NAND flash memory cells. The operating system has no direct line to the NAND chips. All read, write, and delete instructions pass through the controller first, and the controller actually performs the work on the storage medium.

This communication is made possible through the Flash Translation Layer, or FTL. The FTL is a firmware layer in which the controller maintains a mapping between the logical block addresses, as understood by the operating system, and the physical NAND locations of the SSD’s flash memory. This is called logical-to-physical mapping, abbreviated as L2P.

Maintaining the FTL is one of the controller’s core functions, alongside governing the drive’s endurance and data reliability. For recovery, its most important role is deciding how quickly deleted data is physically erased from the flash cells.

How Does the Process of Data Deletion in an SSD Differ From an HDD?

SSDs and HDDs handle data deletion in fundamentally distinct ways, rooted in the physical properties of each storage medium and in how their controllers manage read and write operations.

The core difference comes down to how each drive performs a write. HDDs rely on write-in-place media, while SSDs depend on erase-before-write media. That single architectural choice has major consequences for how deleted data behaves and for how recoverable it remains afterwards.

This is worth examining more closely.

Write-in-Place vs. Erase-before-Write

On a hard disk drive, new data can be written directly over existing data in a single operation. When a file is deleted, the operating system removes its entry from the file system table and marks the corresponding sectors as available. The original data remains physically intact on the platters until a subsequent write operation overwrites those sectors.

SSDs operate differently. NAND flash cells must be fully erased, with all bits set to 1, before they can be programmed with new data by selectively setting bits to 0. When the controller needs to update a file, it writes the new data to a free block and flags the old location for erasure. Direct overwrite is not possible.

This erase-before-write constraint means the drive must manage writes and erasures at different granularities, and that distinction has direct consequences for how the controller coordinates storage and how deleted data behaves on the medium.

NAND Architecture: Pages vs. Blocks

An SSD’s NAND memory is organised and managed through two distinct units. A page is the smallest unit that can be read or written, typically between 4 and 16 kilobytes. Whenever the host requests even a single byte of data, the SSD controller has to read or write an entire page.

A block is the smallest unit that can be erased and typically contains between 64 and several hundred pages. The controller can write to an individual page but cannot erase one. Reclaiming space requires erasing the entire block. If a block contains pages with valid data as well as deleted pages, the controller has to first migrate the valid pages to a clean location. Only then can the original block be erased.

This page-and-block mismatch is an architectural reality that every SSD controller must manage.

The Data Deletion Process in an SSD

The deletion process in an SSD unfolds in three stages.

1. Logical Deallocation: The TRIM Command, What It Does, and What It Does Not Delete

When a user deletes a file, the operating system issues a TRIM command to the SSD controller. The controller flags the corresponding pages as invalid in the FTL mapping.

The data itself is not erased at this stage. It remains physically present in the NAND cells and is only logically unreachable. Each subsequent TRIM command provides the controller with an updated list of Logical Block Addresses (LBAs) that are no longer in use.

Note: The TRIM command marks relevant pages as invalid. It does not remove or alter the data those pages contain.

2. Garbage Collection: The Background Process That Prepares Pages for Permanent Deletion

The SSD controller runs an autonomous process called ‘garbage collection’ to reclaim NAND memory blocks filled with invalid pages. In this process, the controller identifies a dirty block, migrates any remaining valid pages from that block to a clean block, and queues the original block for erasure. The controller typically defers this work to periods when the drive is idle.

3. Physical NAND Erase: Permanent Erasure of Data From NAND Flash Memory

The SSD controller applies a high-voltage pulse between 15 and 20 volts to the block via Fowler-Nordheim tunnelling. This pulse removes the trapped electrons from the flash memory cells and resets every bit in the block to a logical 1. Once this stage is completed, the data is permanently erased.

This three-stage process shows why recovering deleted SSD data is unpredictable. The time window between page deallocation and physical block erase is when data recovery may still be possible.

How Does an SSD Controller Influence The Operations and Resilience of the Drive?

Storing and deleting data is only part of what the controller does. It also keeps the drive running, protects what is stored, and manages cell wear, the focus of this section.

1. Managing Storage

In an SSD, reads and writes are performed at the page level, but erasure occurs at the block level. To work within this constraint efficiently, the controller manages multiple parallel channels and Logical Units (LUNs), a mechanism called parallelism.

The controller distributes operations across these LUNs, starting a new command on one chip while another is still busy with a long-latency program or erase operation. This is called interleaving.

The controller also consolidates small, scattered writes into larger, sequential NAND page programs rather than committing each write individually. It buffers and aggregates them into larger sequential writes to reduce unnecessary wear on NAND cells. This mechanism is called ‘write coalescing’.

To explore how these mechanisms affect error rates and recovery procedures, refer to our comprehensive analysis of Read/Write Errors in SSDs: Causes, Fixes, and Recovery Options.

2. Maintaining Data Integrity

An SSD controller continuously maintains data integrity through two key functions.

The first is error correction. NAND cells develop bit errors as they age, and these accumulate with each program/erase cycle. The controller addresses this using dedicated Error Correction Coding (ECC) engines based on algorithms such as Low-Density Parity-Check (LDPC) or Bose-Chaudhuri-Hocquenghem (BCH). These engines detect and correct flipped bits on every read, ensuring the operating system receives what was originally written.

The second is Power Loss Protection (PLP). In enterprise drives, the controller is paired with capacitors that hold a brief reserve of power. If the drive suddenly loses power, these capacitors give the controller enough time to write any data still in volatile buffers to the NAND.

3. Extending Lifespan

NAND cells have a finite operational lifespan. Each cell can be programmed and erased only a limited number of times, a limit measured in Program/Erase (P/E) cycles. To extend this lifespan, the controller distributes wear across cells using two methods.

The first is dynamic wear levelling, in which the controller directs new writes to blocks that have undergone the fewest P/E cycles. The second is static wear levelling, in which the controller relocates infrequently modified data from low-wear blocks, allowing those blocks to return to active use. Without this, blocks that store static data would remain unused, while others would wear out faster.

SSD controllers also improve reliability through over-provisioning. Manufacturers reserve a portion of the drive’s physical capacity as a hidden pool that is not exposed to the operating system. The controller uses this reserve as a workspace for garbage collection and as a source of spare blocks to replace failed blocks.

Note: For SSD data recovery, over-provisioning introduces another layer of complexity. Data fragments may exist in physical memory outside the operating system’s address range, and a standard file scan cannot examine them because they are not exposed as normal logical storage. This is one reason Stellar SSD data recovery experts assess each device at the media and controller-behaviour level rather than relying on file system output alone.

The Main Types of SSD Controllers Explained

SSD controllers can differ significantly in their architecture. These differences centre on how each one stores and accesses the FTL mapping table.

Since the controller consults this table on every read and write operation, where the table resides has a direct bearing on the drive’s performance, cost, and endurance. The three main controller types are DRAM-based, DRAM-less, and HMB, each taking a different approach to this problem.

1. DRAM-Based Controllers

A DRAM-based controller has its own dedicated memory chip that stores the FTL mapping table. This chip is either integrated into the controller or mounted separately on the drive’s printed circuit board.

Because DRAM operates roughly 100 times faster than NAND, the controller can resolve address lookups with minimal delay, which is the source of these drives’ speed advantage.

The trade-off appears in cost and power consumption. DRAM chips add to the price of a drive and consume more power than other controller designs. There is also the matter of volatility: since DRAM is volatile, its contents are lost the instant power is cut. Higher-end drives in this category address this with onboard capacitors, which hold sufficient charge to allow the controller to write the mapping table to NAND before the drive loses power completely.

2. DRAM-Less Controllers

A DRAM-less controller omits the dedicated memory chip entirely, resulting in a lower-cost, smaller, and more power-efficient drive.

Instead, the controller stores the FTL table directly on the NAND. The most recently used mapping entries are cached in a small amount of Static Random-access Memory (SRAM) embedded within the controller. When a required mapping entry is missing from this small SRAM cache, the controller must fetch it from the NAND before it can read the requested data.

This additional step introduces latency and can reduce the SSD’s random read and write performance. In exchange, an SSD with a DRAM-less controller is inexpensive, smaller, and consumes less power than one with a DRAM-based controller.

Note: For anyone evaluating SSDs by controller architecture, the decision between a DRAM-based and a DRAM-less drive generally comes down to one question: does the cost reduction justify the performance compromise?

3. HMB (Host Memory Buffer) Controllers

The Host Memory Buffer (HMB) controller is a DRAM-less design available on drives that use the Non-Volatile Memory Express (NVMe) interface. It bridges the gap between DRAM-based and standard DRAM-less controllers.

Rather than relying solely on SRAM, the controller uses a small portion of the host system’s RAM to cache a larger portion of the FTL mapping table, typically between 64 and 100 megabytes.

An HMB drive can match the performance of a DRAM-based drive for most workloads, at a fraction of the cost. The trade-off is dependency on the host system. If the operating system does not support HMB or refuses the memory allocation request, the drive operates as a standard DRAM-less controller with no performance advantage.

These architectural differences carry weight beyond performance. For data recovery, the controller type influences which diagnostic methods are viable, which tools apply, and how much of the deleted data remains recoverable.

Conclusion: The Controller Is Where SSD Data Recovery Starts

Every concept covered in this guide points back to one component. The TRIM command reports to it. Garbage collection runs under it. Wear levelling, over-provisioning, and physical NAND erase are all decisions the controller makes, often autonomously, often while the drive sits idle.

By the time a user realises that data has been lost, the controller may already have closed the recovery window. Whether it has depends on the controller’s architecture, the drive’s workload, and how much time has passed.

This is why Stellar Data Recovery experts begin every SSD data recovery case with a controller-level assessment. The type of controller, its manufacturer, and its behaviour under failure conditions determine which diagnostic approach is viable, which tools apply, and what can realistically be retrieved. A file system scan is not sufficient; only a more thorough, controller-level assessment can reveal what is truly recoverable.

Part 2 of this guide covers exactly that, walking through the recovery approach for each controller type and the scenarios where retrieval remains possible.

Lost data on an SSD? Call us on 1800-102-3232

Power down the drive immediately. The longer it remains active, the more the controller narrows what can be retrieved. Stellar’s SSD data recovery specialists will assess what the controller has left behind and advise on the most viable recovery options.

Not all SSD failures present the same way or require the same response. The articles below cover the scenarios users encounter most frequently and how each is handled.

• How To Recover Data From TRIM Enabled SSDs
• Slow SSD Performance: Causes, Fixes, and Data Recovery Options
• Top 10 SSD Hard Drives in India
• How to Fix SSD Bad Blocks and Reallocated Sectors
• Common SSD Errors and Issues—Causes, Fixes and Solutions
• Bad Sectors in HDD & SSD: Causes, Fixes & Data Recovery Guide

Frequently Asked Questions

1. Should I Switch Off My SSD If I Accidentally Delete My Data?

Yes, and immediately. Every operation that runs after data loss gives the controller more opportunities to permanently erase what you are trying to recover. System updates, browser cache, and background writes all trigger controller activity. Each one narrows the recovery window. Power the drive down and keep it off until it is in the hands of a recovery engineer.

2. If I Disable the TRIM Command After Data Loss, Does That Guarantee Recovery?

No. Disabling TRIM removes one deallocation path but does not halt the controller. Garbage collection, wear levelling, firmware routines, and encryption can all continue running independently of TRIM. Any of these processes can permanently erase data that would otherwise have been recoverable. Disabling TRIM buys time, but it does not stop the clock.

3. Can Encryption Affect SSD Data Recovery?

Yes, and it is one of the more complex variables in an SSD recovery case. If full-disk encryption is active and the decryption key is unavailable, the data may be physically present in the NAND but completely unreadable. This applies to both software-based encryption and hardware-level self-encrypting drives. Physical recovery and decryption are two separate problems, and both need to be solved.

4. Does the Type of NAND in the SSD (SLC, MLC, TLC, QLC) Affect Recovery Prospects?

Less than most people assume. The data deletion process, covering TRIM, garbage collection, and physical erase, behaves the same way across all NAND grades. Where NAND type does matter is in bit error rates and overall endurance, both of which affect the drive’s condition over time. For recovery purposes, the controller’s architecture and behaviour carry far more weight than the NAND grade.

5. If I Have a Backup, Do I Still Need SSD Data Recovery?

If the backup is current and complete, no. Use it. Most cases that reach Stellar’s engineers arrive because the backup did not exist, was too old to be useful, or had itself failed. A working backup is the only reliable protection against SSD data loss, because unlike a hard drive, an SSD can close the recovery window before anyone realises data is gone.