On 04/13 04:58, Rich Freeman wrote: > On Mon, Apr 13, 2020 at 4:34 PM antlists <antli...@youngman.org.uk> wrote: > > > > 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 ... > > > > Hmm, found the ATA spec at: > http://nevar.pl/pliki/ATA8-ACS-3.pdf > > In particular page 76 which outlines the LBA addressing for TRIM. It > looks like up to 64k ranges can be sent per trim, and each range can > cover up to 64k blocks. So that is 2^32 blocks per trim command, or > 2TiB of data per TRIM if the blocks are 512 bytes (which I'm guessing > is the case for ATA but I didn't check). The command itself would be > half a megabyte since each range is 64 bits. > > But if the kernel chops them up as you say that will certainly add > overhead. The drive controller itself is probably the bigger > bottleneck unless it is designed to do fast TRIMs. > > -- > Rich >
Hi all, thanks **a lot** for all this great information! :) Since I have a NVMe drive on a M.2 socket I would be interested at what level/stage (?word? ...sorry...) the data go a different path as with the classical sata SSDs. Is this just "protocol" or there is something different? On the internet I read, that the io-scheduler is choosen differentlu by the kernel, if there is a NVMe driven detected, for example. (I think, the io-scheduler has nothing to do with the fstrim operation itsself (I think...) -- it is there only as an example...) I think, due to the corona lockdown I have to fstrim my hair myself.... :) 8) Cheers! Meino
