
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. Details follow: 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. craig PS: i was already thinking of reformatting these SSDs with ext4 anyway. They're mostly used as boot & OS drives, with bulk storage on a ZFS volume so don't need XFS. gives me a good excuse to replace the Torqx2 with a Pyro :) (and the Torqx2 can go into my mythtv box where it'll speed up the mythtv mysql database). -- craig sanders <cas@taz.net.au>

On Sat, 7 Jan 2012, 13:28:41 EST, Craig Sanders <cas@taz.net.au> wrote:
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.
This was discussed on the btrfs list recently for the same reason (ext4 vs btrfs behaviour). The FS does send the trims to the device in both cases but ext4 remembers what's been trimmed whilst that fs is mounted. It's not recorded in the the ext4 fs though so if you remount it'll trim again. cheers, Chris -- Chris Samuel - http://www.csamuel.org/ - on mobile

On Sat, Jan 07, 2012 at 02:02:02PM +1100, Chris Samuel wrote:
On Sat, 7 Jan 2012, 13:28:41 EST, Craig Sanders <cas@taz.net.au> wrote:
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.
This was discussed on the btrfs list recently for the same reason (ext4 vs btrfs behaviour).
URL?
The FS does send the trims to the device in both cases but ext4 remembers what's been trimmed whilst that fs is mounted. It's not recorded in the the ext4 fs though so if you remount it'll trim again.
OK, that sounds like it's some sort of optimisation in ext4 so that subsequent fstrim runs are faster. I'm still not sure why fstrim says (on the 2nd and subsequent runs on XFS) that it has trimmed almost the same amount of data. what is it actually counting here? bytes in data blocks that (might) need trimming? byte-counts in TRIM commands sent to the device? something else? something still seems screwy, or at least counter-intuitive. craig -- craig sanders <cas@taz.net.au> BOFH excuse #243: The computer fleetly, mouse and all.

On Sat, 7 Jan 2012, 14:27:19 EST, Craig Sanders <cas@taz.net.au> wrote:
URL?
Umm, not sure, it's in my inbox. :-) This looks like the thread: http://comments.gmane.org/gmane.comp.file-systems.btrfs/15027
OK, that sounds like it's some sort of optimisation in ext4 so that subsequent fstrim runs are faster.
Correct.
I'm still not sure why fstrim says (on the 2nd and subsequent runs on XFS) that it has trimmed almost the same amount of data.
Because XFS doesn't remember what was trimmed so sends the same list (plus any new ones) down to the FS I'd guess.
what is it actually counting here? bytes in data blocks that (might) need trimming? byte-counts in TRIM commands sent to the device? something else?
Not a clue I'm afraid - this man page indicates its bytes the FS has sent to the block layer to be trimmed: http://manpages.ubuntu.com/manpages/oneiric/man8/fstrim.8.html cheers, Chris -- Chris Samuel - http://www.csamuel.org/ - on mobile

On Sat, Jan 07, 2012 at 03:56:48PM +1100, Chris Samuel wrote:
This looks like the thread:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/15027
ta. interesting thread.
Because XFS doesn't remember what was trimmed so sends the same list (plus any new ones) down to the FS I'd guess.
that's weird. if they're already trimmed, why is it sending the same blocks? makes me wonder how it's building the list of blocks-to-be-trimmed. hmmm...probably the full list of free blocks, whereas ext4 sends the full list minus those it knows it has already trimmed (an obvious when you think about it, but still clever optimisation).
what is it actually counting here? bytes in data blocks that (might) need trimming? byte-counts in TRIM commands sent to the device? something else?
Not a clue I'm afraid - this man page indicates its bytes the FS has sent to the block layer to be trimmed:
http://manpages.ubuntu.com/manpages/oneiric/man8/fstrim.8.html
yep, I read the man page, wasn't really expecting an answer from you...just wondering aloud :) craig -- craig sanders <cas@taz.net.au> BOFH excuse #11: magnetic interference from money/credit cards
participants (2)
-
Chris Samuel
-
Craig Sanders