The SSD looks at these "hints" provided by TRIM and verifys that all the blocks Windows says are empty have been erased. Anything that has not been erased will become erased as a result of the hints provided by TRIM.
This part is still wrong. SSDs are so significantly more complex than HDDs that you'll just have to excuse me for the fact that it took a while before I decided to write my reply. I also tried to keep it short, but failed.
For starters, Windows sends the TRIM command each time when it deletes some data from the filesystem. The filesystem presents data in the form of logical blocks, and, it maps these logical blocks to physical blocks. On a SSD (but not on a HDD),
physical blocks are referred to as
pages, and, pages are grouped into blocks, but these blocks are not to be confused with the aforementioned
physical blocks nor are to be confused with the aforementioned
logical blocks. So, in the specific context of how data is stored internally on SSDs, the term "block" has an entirely different meaning.
On SSDs, data is read and written at the page level but must be erased at the block level. This also means that these "hints" that mark certain parts of the data as
stale are applied at the page level, not at the block level.
Stale data is the part of the data that no longer is needed by the filesystem to store its data. So, on SSDs, a stale page is a page that is marked such that it is allowed to be erased by a maintenance process known as garbage collection, which runs internally on the SSD, and is controlled by the SSD, whereas a free page is a page that either has never been written or has been erased by garbage collection.
The SSD looks at these "hints" provided by TRIM before it decides what to do with these hints. Keeping track of the hints is a process that causes some additional workload on the SSD. So, during those moments when heavy I/O activity on the SSD is causing slowdowns, the controller on the SSD may actually decide to disregard the hints. It still processes the TRIM commands, but it doesn't necessarily always preserve the hints.
Due to the simple fact that some hints can be lost in this manner, Windows sends the same TRIM commands again, once per week if you leave the optimization at its default setting. In Windows, this re-sending of the hints is what they call a
retrim. (The retrim action sends TRIM commands, as there exists no such thing as a retrim command.) Windows runs the optimization as a maintenance task so it is scheduled to run during those moments when the I/O activity on the SSD will hopefully be more relaxed.
If it's still too busy when the retrim happens, the SSD could potentially throw away some of the hints again, but then, at worst the negative impact from this should still turn out to be negligible in the end, for most users anyway, as these hints still keep getting re-sent every week by default on Windows 11. (In the possible event that you don't subscribe to the club of "most users", you could always consider to buy Condusiv DymaxIO...)
The retrim action is not the only action that is included in the optimization, though. The optimization also performs an analysis, followed by a partial defrag of the SSD if the analysis results indicate that a partial defrag will be beneficial to it, but this analysis is skipped during the optimization until after (by default) one month has passed since the last time when it wasn't skipped.
The analysis also takes into account the fact that excessively defragging a SSD shortens its lifespan so, it doesn't defrag the SSD more than what's needed to achieve some certain approximation of "good" tradeoff between longevity and performance. (DymaxIO offers a lot better optimization, BUT... for "most users", due to how they use their computer, this improvement has no noticeable effect, or it barely does, whereas on heavy workstations and servers, this difference can very often be enormous.)
On the particular subject of
when the stale pages will actually be freed. The assertion, that the erase will never/unlikely be postponed by the SSD for very lengthy periods of time is totally incorrect. On many occasions it can actually even be delayed indefinitely. The following explanation is just an oversimplification, but it gets the idea across.
The SSD has a threshold. Stale pages aren't freed until the number of free pages drops below this threshold. The SSD also has a
critical threshold. I/O operations have a higher priority than freeing stale pages above this critical number so, during those moments when freeing stale pages would cause I/O operations to suffer slowdowns, stale pages aren't freed until the number of free pages drops below this critical threshold.
To reclaim pages with the stale data, the pages with the good data must first be moved to another block so the original block can be erased. This constant shifting of data results in many more program/erase (P/E) cycles than requested by the host system, a situation referred to as write amplification.
Most controllers also incorporate wear leveling into their garbage collection operations to distribute P/E cycles more evenly across the storage blocks to prevent overused blocks from wearing out. So, to improve the wear leveling strategy, and to reduce write amplification, SSDs don't erase all of the stale data almost immediately.
Instead, they tend to wait it out to a very large degree so that they can continue to gather additional statistical details for longer about what would probably be the more efficient route to take to perform the maintenance, and to further increase the likelihood of growing increasingly more efficient. That is, by proactively planning ahead, also by means of predictions, the accuracy of which heavily relies on the thoroughness of statistics that these predictions will be based on.
lc-tech.com
