On Wed, Jul 17, 2019 at 12:02:00PM +0300, Lennert Buytenhek wrote: > Any ideas on what I can try to speed this up? I can't help with the kernel side of things. Hopefully it can be improved somehow. But until there is a fix you could maybe work around it with fstrim --offset and --length and --minimum options to trim a smaller segment at a time instead of everything. (You get this behavior for free with ext4, as long as you don't reboot/remount the filesystem it avoids trimming the same areas over and over - XFS trims all.) Total time (this is tmpfs-backed, no real I/O) | # time fstrim -v /mnt/tmp/ | /mnt/tmp/: 14 TiB (15360592805888 bytes) trimmed | | real 4m8.962s | user 0m0.000s | sys 0m44.533s Segment time (pick a size that works for you) (Why XFS trims 900G when I said 500G is a bit of a mystery... this option is only rarely used, perhaps some testing is in order? Not sure if it's perfectly safe...!) | # time fstrim -v --minimum 64M --offset 0G --length 500G /mnt/tmp/ | /mnt/tmp/: 894.2 GiB (960171012096 bytes) trimmed | | real 0m16.183s | user 0m0.004s | sys 0m2.782s And instead of offset 0G you could give (if it's a daily cron) it as "$(( $(date +%j) % totalsegments * length ))G" or something of the like, to cover the entire array every so many days. Not a fix in any way but maybe a workaround to make it more bearable. Regards Andreas Klauer
