On Mon, Apr 13, 2020 at 9:18 AM <tu...@posteo.de> wrote: > > One quesion -- not to express any doubt of what you wrote Rich, but onlu > to check, whether I understand that detail or not: > > Fstrim "allows" the drive to trim ittself. The actual "trimming" is > done by the drive ittself without any interaction from the outside > of the SSD. > ... > On the one hand, the SSD drive keeps track of the information, what > blocks are used and unused. And trimming is done by the drive in > itsself. On the other hand trimming is "just giving the drive more > information about...." > > What kind of information does the commandline tool fstrim transfers to > the SSD beside the command "fstrim yourself" (an ioctl, I think?), > which is needed to fstrim the blocks and what kind of information is > the SDD collecting itsself for this purpose? >
So, "trimming" isn't something a drive does really. It is a logical command issued to the drive. The fundamental operations the drive does at the physical layer are: 1. Read a block 2. Write a block that is empty 3. Erase a large group of blocks to make them empty The key attribute of flash is that the physical unit of blocks that can be erased is much larger than the individual blocks that can be read/written. This is what leads to the need for TRIM. If SSDs worked like traditional hard drives where an individual block could be rewritten freely then there would be no need for trimming. Actually, drives with 4k sectors is a bit of an analogy though the cost for partial rewrites on a hard drive is purely a matter of performance and not longevity and the 4k sector issue can be solved via alignment. It is an analogous problem though, and SMR hard drives is a much closer analogy (really no different from 4k sectors except now the magnitude of the problem is MUCH bigger). Whether you use TRIM or not an SSD has to translate any logical operation into the three physical operations above. It also has to balance wear into this. So, if you don't use trim a logical instruction like "write this data to block 1" turns into: 1. Look at the mapping table to determine that logical block 1 is at physical block 123001. 2. Write the new contents of block 1 to physical block 823125 which is unused-but-clean. 3. Update the mapping table so that block 1 is at physical block 823125, and mark 123001 as unused-but-dirty. Then the controller would have two background tasks that it would run periodically: Task 1 - look for contiguous regions marked as unused-but-dirty. When one of the right size/alignment is identified erase it physically and mark it as unused-but-clean. Task 2 - if the amount of unused-but-clean space gets too low, then find areas that have fragmented unused-but-dirty space. The used space in those regions would get copied to new unused-but-clean blocks and remapped, and then task 1 will erase them and mark them as clean. This deals with fragmented unused space. Every SSD will do some variation on this whether you ever use the trim command as it is necessary for wear-leveling and dealing with the physical erase limitations. Now, in this hypothetical case here is how the drive handles a TRIM command. If it gets the logical instruction "TRIM block 1" what it does is: 1. Look at the mapping table to determine that logical block 1 is at physical block 123001. 2. Mark physical block 123001 as unused-but-dirty in the mapping table. That's all it does. There are four ways that a drive can get marked as unused on an SSD: 1. Out of the box all blocks are unused-but-clean. (costs no operations that you care about) 2. The trim command marks a block as unused-but-dirty. (costs no operations) 3. Block overwrites mark the old block as unused-but-dirty. (costs a write operation, but you were writing data anyway) 4. Task 2 can mark blocks as unused-but-dirty. (costs a bunch of reads and writes) Basically the goal of TRIM is to do more of #2 and less of #4 above, which is an expensive read-write defragmentation process. Plus #4 also increases drive wear since it involves copying data. Now this is all a bit oversimplified but I believe it is accurate as far as it illustrates the concept. A real drive probably groups logical blocks a bit more so that it doesn't need to maintain a 1:1 block mapping which seems like it would use a lot of space. Again, it is a bit like a filesystem so all the optimizations filesystems use like extents/etc would apply. At the physical level the principle is that the drive has to deal with the issue that reads/writes are more granular than erases, and everything else flows from that. The same issue applies to SMR hard drives, which were discussed on this list a while ago. -- Rich
