Why an SSD slows down when full: TRIM, garbage collection and over-provisioning

A new SSD writes into clean NAND quickly. Months later, the same benchmark can fall sharply when the drive is nearly full or has been under sustained writes. The controller has not forgotten how to write. It has less room to prepare clean blocks, so each host write can trigger more internal movement.

Understanding the slowdown requires separating three terms that are often treated as synonyms: TRIM, garbage collection and over-provisioning.

NAND cannot overwrite a used page in place

NAND flash programs data in pages but erases data in larger blocks. When the host updates a small file, the SSD normally writes the new version elsewhere and marks the old page invalid. Eventually a block contains a mix of valid and invalid pages.

Before that block can be erased and reused, the controller must:

1. read the valid pages;
2. copy them to another location;
3. erase the whole block;
4. make the clean block available for new writes.

That background movement is part of garbage collection. When many clean blocks are available, the controller can schedule it efficiently. When the drive is packed and the workload never pauses, it has fewer choices and may perform read-modify-write work in the foreground. Kingston explains that this extra cycle reduces performance and increases write amplification [1].

TRIM tells the SSD what is no longer needed

Deleting a file changes the filesystem, but the SSD does not understand the filesystem's directory. Without help, it may treat deleted logical blocks as valid data that must be preserved during garbage collection.

TRIM lets the operating system tell the SSD that specified logical ranges are no longer needed. The controller can then discard those pages during cleanup instead of copying them [1].

TRIM therefore:

• comes from the host or operating system;
• identifies stale logical data;
• reduces unnecessary internal copying;
• requires support through the whole path, including drivers, RAID or external bridges.

It does not itself perform every block move, and it is not proof of secure erasure.

Garbage collection is inside the controller

Garbage collection (GC) is firmware work inside the SSD. It consolidates valid pages and erases blocks to create clean write space [1][2]. It can operate even without host TRIM, but it is more efficient when it knows which logical data is stale.

GC needs resources:

• free or reserved NAND space for moving valid pages;
• controller time;
• power;
• often periods with less host I/O.

Crucial notes that its active garbage collection needs the SSD powered and idle, with empty space available [4]. Exact algorithms differ by vendor, so a long idle period is not a universal repair command, but sustained 100% activity clearly leaves less opportunity for background maintenance.

Over-provisioning gives the controller private workspace

Over-provisioning (OP) is NAND capacity reserved for controller use and not exposed as normal user LBAs. It supports garbage collection, wear levelling, bad-block replacement and sustained writes.

Micron demonstrates that more OP gives the controller more locations to move valid pages and can improve random-write IOPS under the same firmware and workload [2]. The trade-off is straightforward: less usable capacity in exchange for more working room and potentially steadier performance and endurance.

There are two related but different ways to create headroom:

• Filesystem free space: deleted or unused logical ranges that can help when TRIM reaches the SSD.
• Explicit OP / unallocated capacity: space kept outside the user partition or configured as controller-only capacity, depending on the drive and tool.

Do not assume that an empty folder automatically equals guaranteed OP. Check how the specific SSD and management tool implement it.

Why “90% full” is not a universal cliff

SSD designs differ in native OP, NAND type, controller, firmware, cache and workload tuning. A light read-heavy laptop can remain responsive at a fill level that severely hurts a small drive under continuous random writes.

Crucial recommends keeping at least 10% free for its active garbage-collection process [4]. Treat that as a useful consumer baseline, not an industry law. For an NVR, database, cache or industrial logger, measure steady-state latency and write amplification at the expected fill level, then size OP accordingly.

Check these before blaming capacity

A full drive is one possible cause of slower writes, not the only one:

• SLC cache exhaustion: a short benchmark measures cache; a long copy reaches native NAND speed.
• Thermal throttling: NVMe controllers reduce speed when temperature crosses their limits.
• Interface bottleneck: USB enclosure, cable, PCIe lanes or SATA link caps throughput.
• TRIM path missing: some RAID layers or bridges may not pass discard commands.
• Encryption or background work: antivirus, indexing, updates and encryption change the workload.
• Drive wear or errors: SMART warnings, media errors and low spare need separate investigation.
• Different test state: empty-drive marketing results and a full steady-state drive are not equivalent.

Use NVMe SMART health fields to separate maintenance pressure from a reliability warning.

A safe recovery checklist

1. Back up important data.
2. Check SMART/health, temperature and firmware first.
3. Confirm the interface is running at its expected link speed.
4. Verify the operating system and full storage path support TRIM.
5. Free meaningful space and empty the recycle/trash system.
6. Run the operating system's SSD-aware optimize/ReTrim function; Microsoft documents Optimize-Volume -ReTrim for SSD media [3].
7. Allow normal powered idle time where the vendor recommends it.
8. Retest with the same file size, fill level, cache state and temperature.

If performance remains low but health is clean, compare it with the product's sustained, post-cache specification rather than its peak package number.

Bottom line

An SSD slows near full because NAND cleanup needs somewhere to move valid data. TRIM identifies stale logical ranges, garbage collection creates clean blocks, and over-provisioning gives the controller private room to do that work. Leave headroom, make sure TRIM reaches the drive, and test sustained performance at the real workload and fill level. If errors or critical warnings appear, treat it as a health issue, not a housekeeping problem.