TRIM is unrelated to defrag, it's a necessary SSD cleanup operation that's usually postponed so immediate write performance isn't impacted.
A rough analogy is you don't run backups in the middle of your work day. You could, but that leads to poor performance. By delaying TRIM, a SSD can keep up with a heavy write workload and you can schedule cleanup for later.
Windows defrag has the ability to run TRIM about once a month.
Other vendor SSD tools can do TRIM at other times, or on-demand.
Yes and no. TRIM is indirectly related to defrag in the particular sense that both are necessary to help mitigate SSD performance degradations and accelerated aging of the NAND cells.
TRIM only marks blocks in the NAND as invalid, or stale to indicate that
garbage collection is allowed to erase them. However, individual blocks cannot be erased in NAND. Only an entire page can be. (NAND pages consist of multiple blocks.) As a result, garbage collection commonly will decide to
postpone erasure of a page until all blocks in the page are marked as stale by TRIM. Various other reasons why a lot of erasures very often are postponed for (much) longer periods of time than many think include wear leveling, a strategy to distribute erasures a lot more evenly across all pages, the purpose of which is to avoid wearing out some pages a lot sooner than others. As a matter of fact, many stale blocks never are erased at all. It's why secure deletion tools like SDelete (from Sysinternals) don't work on SSDs, I digress...
Further, file fragmentation still has an impact on SSDs due to the fact that accessing each fragment requires at least one I/O request. Even if you have a lot of IOPS (I/O operations per second) on tap, you might still nevertheless bump into bottlenecks. This is because each I/O still takes time to complete. I.e., while it is true that reading/writing smaller chunks of data takes less time to complete than reading/writing bigger chunks of data, the latter option still gives much better
sequential data transfer speeds and, as a consequence, much better
throughput. The assertion that none of it should matter on SSDs because you can never run out of IOPS is the so-called "IOPS fallacy", and, this fallacy can also be measured with relative ease. Hammering the controller of the SSD with more numerous, more frequent I/O requests also increases the controller's workload so as a result it has less available time to spend on its own internal optimization mechanisms making them less effective, worsening the inherent problem of write amplification among various other negative tendencies.
Finally, on Windows 11 by default, the
retrim part (which sends the same TRIM commands again, hence it's called retrim) runs once per
week on the SSDs. You can verify this by pasting the command below in a PowerShell window.
Get-WinEvent -FilterHashtable @{LogName='Application';ProviderName='Microsoft-Windows-Defrag'} |% {$x=[xml]$_.ToXml(); If($_.Id -eq 258 -Or $_.Id -eq 264) {If($x.Event.EventData.Data[1] -ne $z) {$z=$x.Event.EventData.Data[1];$y='~'} else{$y=''}; $_ |select @{l='TimeCreated';e={$_.TimeCreated}}, @{l='Level';e={"$($_.Level) $($_.LevelDisplayName)"}}, Id, @{l='~';e={$y}}, @{l='Volume';e={$z}}, @{l='Hex';e={"$([String]$x.Event.EventData.Binary[10])$([String]$x.Event.EventData.Binary[11])$([String]$x.Event.EventData.Binary[8])$([String]$x.Event.EventData.Binary[9])"}}, @{l='Data';e={$x.Event.EventData.Data[0]}}, @{l='Message';e={$x.Event.EventData.Data[2]}} }} |? {$_.Hex -eq '02AD'} |ogv -Title 'Retrim'
