On 13/04/2020 17:05, Rich Freeman wrote:
And what takes time when doing a "large" TRIM is transmitting a
_large_ list of blocks to the SSD via the TRIM command. That's why
e.g. those ~6-7GiB trims I did just before (see my other mail) took a
couple of seconds for 13GiB ~ 25M LBAs ~ a whole effin bunch of TRIM
commands (no idea... wait, 1-4kB per TRIM and 4B/LBA is max. 1k
LBAs/TRIM and for 25M LBAs you'll need minimum 25-100k TRIM
commands... go figure;) no wonder it takes a second or few;)
There is no reason that 100k TRIM commands need to take much time.
Transmitting the commands is happening at SATA speeds at least. I'm
not sure what the length of the data in a trim instruction is, but
even if it were 10-20 bytes you could send 100k of those in 1MB, which
takes <10ms to transfer depending on the SATA generation.
Dare I say it ... buffer bloat? poor implementation?
aiui, the spec says you can send a command "trim 1GB starting at block
X". Snag is, the linux block size of 4KB means that it gets split into
loads of trim commands, which then clogs up all the buffers ...
Plus all too often the trim command is synchronous, so although it is
pretty quick, the drive won't accept the next command until the previous
one has completed.
Cheers,
Wol
