> I've been running into an issue with background fstrim on > large xfs filesystems on RAID10d SSDs taking a lot of time to > complete and starving out other I/O to the filesystem. There > seem to be a few different issues involved here, [...] Doing > this on actual 4x7.68TB or 6x7.68TB SSD arrays instead of with > loop devices takes many many hours. Amazingly unexpected news :-). Stop the presses! "Complex and expensive operation based on a misdesigned primitive takes a long time when scaled to huge volumes!!!!!!!!!!!!!!!!!!!!!!!". In other news ursinids have been see relieving themselves in areas with many trees. > Any ideas on what I can try to speed this up? [...] Develop a time machine and travel back in time to persuade the authors of the TRIM spec to make it non-blocking? Send patches to improve most host adapter and disk firmware? > but the main one appears to be that BLKDISCARD on a RAID10 md > block device sends many small discard requests down to the > underlying component devices (while this doesn't seem to be an > issue for RAID0 or for RAID1). If you think that can be improved (and it can be improved, at a very high cost), send patches :-). > [...] the completion time is somewhat inversely proportional > to the RAID chunk size. [...] How strange is that! :-) > It's quite easy to reproduce this with just using in-memory > loop devices [...] For pretty small values of "reproduce"...
