Does anyone use fstrim on an XFS formatted SSD partition?
I’ve got two systems with XFS root partitions that fstrim seems to do (almost) nothing on, but it seems to work correctly on another system with formatted with ext4.
System 1 is an AMD 1090T with a Patriot Torqx 2 128GB SSD. System 2 is also an AMD 1090T with a Patriot Pyro 120GB SSD.
I’ve been running both for several months without any TRIM support because I (incorrectly) assumed that XFS’ support for TRIM was automatically enabled. I’ve recently discovered that it’s not, and also that it’s better performance-wise to run fstrim regularly from cron for ‘batch-mode’ TRIM operations.
Anyway, System 1 takes over 7 minutes to run fstrim, and claims to have trimmed about 16GB….but if i run it again it still takes over 7 minutes and claims to have trimmed about the same amount of data (slightly less).
# time fstrim -v / /: 16777764864 bytes were trimmed real 7m31.089s user 0m0.004s sys 0m9.705s # time fstrim -v / /: 16772276224 bytes were trimmed real 7m8.973s user 0m0.000s sys 0m9.165s
System 2 takes over 28 minutes to run fstrim and claims to trim about 51GB of data (it’s had an SSD for a lot longer than System 1. It also has /home on /, whereas System 1 has /home on a separate disk). Similarly, running it again immediately afterwards also takes about the same amount of time and claims to trim about the same amount of data.
# time fstrim -v / /: 51594948608 bytes were trimmed real 28m19.832s user 0m0.000s sys 0m6.264s # time fstrim -v / /: 51499814912 bytes were trimmed real 28m29.230s user 0m0.000s sys 0m6.328s
(interestingly, the Pyro is a *much* faster SSD than the Torqx2. it’s SATA3 and is capable of about 500-550MB/s. The Torqx 2 is SATA 2 and is capable of about 230MB/s…seems as if TRIM speed is roughly the
same for both drives, proportional to the amount of data to be trimmed. almost certainly limited by the flash speed with the internal controller differences being negligible for this task)
OK, so it seems as if fstrim claims X bytes were trimmed, but it doesn’t actually happen.
On a third system, I have / on an SSD formatted with ext4. System 3 is an Intel Xeon E5607, and the SSD is an OCZ AGILITY3 120GB.
# time fstrim -v / /: 14267424768 bytes were trimmed real 2m25.222s user 0m0.000s sys 0m0.636s # time fstrim -v / /: 0 bytes were trimmed real 0m0.001s user 0m0.000s sys 0m0.000s
on ext4 fstrim seems to work as expected. The OCZ SSD is also a LOT faster than the Patriot SSDs (roughly 14GB trimmed in 2.5 minutes).
anyone seen this before? is it a bug in XFS’ SSD handling? or am i just misinterpreting the results? my google-fu can’t find anyone with similar problems, just mailing list articles and an XFS wiki page saying that it works, and that running fstrim regularly is recommended over using the ‘discard’ mount time option.
Someone just emailed me about this, so I thought I better post an update for the next person who encounters this non-problem…
It turns out that ext4 caches the list of blocks that have been trimmedÂ since the last reboot, and only trims those that haven’t yet beenÂ trimmed. XFS goes through the entire block list.
XFS still correctly trims the no-longer-used blocks. it just takes a bitÂ longer without that optimisation.Â