On Wed, May 18, 2022 at 8:50 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > I suspect that it's just that your storage device is really slow at > small trims. If you didn't set a minimum trim size, XFS will issue > discards on every free space in it's trees. If you have fragmented > free space (quite possible if you're using reflink and removing > files that have been reflinked and modified) then you could have > millions of tiny free spaces that XFS is now asking the storage to > free. Yeah, fstrim man page says minimum-size default is 0, so it'll trim every filesystem free block. I asked about it a while ago in linux-block@ list and didn't get a reply, maybe it's the wrong list. https://lore.kernel.org/linux-block/CAJCQCtRM4Gn_EY_A0Da7qz=MFfmw08+oD=syQEQt=9DrE8_gFw@xxxxxxxxxxxxxx/ If the context includes trim down to SSD hardware, and if the workload involves lots of small files, and many/most of the mixed used+free portions of the filesystem blocks look like swiss cheese, then I suppose 1M granularity means quite a lot isn't trimmed, and ends up getting needlessly moved around by the firmware's wear leveling? But oh well? Maybe in that case the discard mount option makes more sense. But if context is only LVM thin provisioning, and not pass through to an SSD, then a 4M granularity is adequate (match the LVM logical extent size). I'm offhand not imagining a benefit to trimming thin provisioning less than LE size. -- Chris Murphy
