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.

fstrim and XFS is a post from: Errata

Sometime within the last few months, an upgrade prevented Chromium from finding its application icon…with the result that when minimised (or displayed in the panel window list or Alt-Tab) it used the default application icon.

It looks to me as if the problem is that Chromium is now looking for chromium-browser.svg but chromium.svg is what's on my debian system.

To restore, all you need to do is:

$ mkdir -p ~/.local/share/icons/hicolor/scalable/apps
$ cd ~/.local/share/icons/hicolor/scalable/apps
$ ln -s /usr/share/icons/hicolor/scalable/apps/chromium.svg chromium-browser.svg

great, done. Now my chromium windows don't look the same as my mrxvt windows in Alt-Tab, they're quite clearly Chromium windows. The icon now looks like this: rather than an icon i'd insert here if i knew what its filename is – it looks like a white window with a blue title bar and a thinner blue bar at the bottom (about half the height/thickness of the "title bar") I've spent half an hour searching for it and have given up – anyone know what it is?

alternatively, use cp rather than ln – just in case some future upgrade removes or renames the chromium.svg file

How to set the application icon for chromium is a post from: Errata

The easiest way to do it in debian is to use update-alternatives to "install" a new alternative x-session-manager.

update-alternatives --install /usr/bin/x-session-manager x-session-manager \
/usr/bin/gnome-session-fallback 100 --slave /usr/share/man/man1/x-session-manager.1.gz \
x-session-manager.1.gz /usr/share/man/man1/gnome-session.1.gz

This gives gnome-session-fallback a much higher priority than gnome-session so is unlikely to be bumped by any other session managers that might get installed/upgraded

Setting gnome-fallback as the default session is a post from: Errata