Am 17.07.19 um 22:27 schrieb Peter Grandi: > [...] >> Total time (this is tmpfs-backed, no real I/O) > > That's not even remotely realistic. > >> (Why XFS trims 900G when I said 500G is a bit of a mystery... > >>> # time fstrim -v --minimum 64M --offset 0G --length 500G /mnt/tmp/ > > My guess is that those limiting options are advisory: they rely > on the ability of the filesystem code to easily and cheaply > check whether a given range of physical addresses is free or > used. Many filesystems have a "free list" optimized for the > forward mapping fast "find a free block", not the reverse > mapping "check whether a block is free". > > A good option would have been to not do 'fstrim'/'blkdiscard' > and put TRIM in 'fsck' (apparently that happens under MacOS X > and 'e2fsck' also allows that). how often do you reboot at all and then check your filesystems versus blocks freed /data deleted? and yes, fstrim takes ages after a reboot on a ext4 RAID10 with 2 TB free space and it got worser with Linux 5.0
