SSD TRIM and Garbage Collection: Why Sustained Write Speed Degrades Over Time
A brand new SSD writes at its full rated speed because every block on the drive is empty and ready to accept data immediately. Months later, the same drive under the same workload can write noticeably slower — not because the flash has worn out, but because of how NAND actually handles overwriting used space.
NAND flash has a structural quirk that doesn't exist on a mechanical drive: it can be written to freely, but it can only be erased in large blocks, and a block must be fully erased before any part of it can be rewritten. On a freshly formatted drive, every block is already erased and empty, so the controller can write directly to it at full speed. As the drive fills and gets used over time, that stops being true, and the drive has to do extra work behind the scenes to keep writing quickly.
Write amplification: why one write isn't always one write
When you overwrite data that's spread across partially-used blocks, the SSD controller can't just write the new data over the old — it has to read the valid data still needed from that block, combine it with the new data, write the combined result to a different, already-erased block, and then erase the original block for reuse. This process, called write amplification, means the physical NAND sometimes performs several times more write and erase work than the amount of data the host system requested. A drive that's mostly full and has been used heavily naturally has fewer available pre-erased blocks to write into directly, so more operations require this read-modify-write cycle, and sustained write speed drops as a direct result.
What TRIM actually does
When a file is deleted at the OS level, the SSD controller isn't automatically told those blocks are free — without TRIM, the drive still considers that space "in use" from a flash-management perspective until something else overwrites it, because file deletion at the filesystem level just removes the file table entry, not the underlying data. The TRIM command lets the operating system explicitly tell the SSD which blocks no longer hold valid data, so the controller can mark them for erasure ahead of time rather than discovering during a write operation that it needs to preserve and relocate data that's actually already deleted.
Without TRIM support or with it disabled, every block eventually looks "full" to the controller even as the filesystem reports substantial free space, because the drive has no way to know which of that space is genuinely free versus just marked deleted at the OS level. This is why TRIM matters enormously for sustained performance on modern SSDs and why virtually all consumer operating systems enable it by default for drives that support it — Windows, for instance, runs a scheduled TRIM pass automatically rather than relying solely on real-time TRIM per delete operation.
Garbage collection: the drive's own housekeeping
Independent of TRIM, SSD controllers run background garbage collection — consolidating still-valid data from partially-used blocks into fewer, more densely packed blocks, then erasing the now-fully-empty blocks that result, building up a pool of pre-erased blocks ready for fast writes. This runs during idle periods when the controller isn't busy servicing host read/write requests, which is why a drive that's rarely idle (constantly under load in a server or heavy workstation use case) can show more sustained performance degradation than the same drive in a desktop that sits idle for hours each day, giving garbage collection more opportunity to run.
Overprovisioning: giving the controller more room to work with
SSDs reserve a portion of their total NAND capacity that never appears in the drive's advertised usable capacity, specifically to give the controller a buffer of always-available erased blocks for write amplification and garbage collection to work with, independent of how full the user-visible capacity gets. Enterprise and high-endurance drives typically reserve more of this hidden capacity than consumer drives, which is a meaningful part of why they sustain write performance more consistently under continuous heavy load — more overprovisioning means the controller has more headroom before write amplification and garbage collection start competing directly with host write requests for the same limited pool of erased blocks.
Users can manually increase overprovisioning on a consumer drive by partitioning it to use less than its full advertised capacity, leaving the remainder unpartitioned and available to the controller as extra buffer space. This has a measurable effect on sustained write consistency for drives used in write-heavy scenarios, though it comes at the direct cost of usable storage capacity, which is why it's a workload-specific decision rather than a universal recommendation — it matters far more for the kind of continuous heavy writes seen when diagnosing NVMe thermal throttling under sustained transfer than for typical desktop usage patterns.
fsutil behavior query DisableDeleteNotify should return 0), check how full the drive actually is, and consider whether the workload keeps it too consistently busy for garbage collection to catch up during idle periods.