I bet you know this - sometimes you’re researching something on the web, take a wrong turn, and an hour or two later you find yourself immersed in some stuff that, while very interesting, has nothing to do with what you were looking for.

This is how I recently found out that for the last two years I only thought I had enabled TRIM for the SSD in my ThinkPad.

Turns out that just having the discard mount option in /etc/fstab doesn’t do anything if youre using LVM and/or dmcrypt. To quote the article:

The first thing to know is that TRIM should be enabled on all I/O abstraction layers. This means that if you have an ext4 partition on top of LVM, which in turn is on top of an encrypted volume with LUKS/dm-crypt, then you must enable support for TRIM in these three layers: The filesystem, LVM and dm-crypt. There is no point in enabling it at the filesystem level if you don’t enable it also on the other layers. The TRIM command should be translated from one layer to another until reaching the SSD.

I also learned about fstrim, which you can use instead of the discard mount option to deal with TRIM. It’s a command line program you can launch whenever you see fit, and which will then scan your file system and do all the necessary TRIM stuff in one go. This way you avoid the performance penalty of discard which acts in real time after file deletion. The trade off is that your system will be busy from a few seconds to several minutes when fstrim is running from time to time, depending on how much work there is to do.

The Archlinux Wiki also strongly favors fstrim over discard.

So when I found out that discard never actually worked on my system due to missing configuration for LVM and dmcrypt, I decided to use this opportunity to do some basic before / after benchmarking so I could see the effect of the very first fstrim on that drive.

The Situation

The machine in question is my main work horse, a 2 year old ThinkPad X230, which was pimped with a 500GB Samsung SSD 840 PRO immediately after arrival. It’s been nearly in daily use since then. The SSD is currently 65% full and according to the SMART stats has been running for around 3200 hours until now.

For the sake of simplicity I chose gnome-disk-utility to do the before/after benchmarks. Given an otherwise non-busy system it showed very little variation between test runs, so I figured it would be good enough to show the effect of TRIM, if there is any.

So here’s a result from a read-only benchmark run before enabling TRIM:

Unfortunately I don’t have a comparable benchmark from the time when the drive was new, but from looking at the numbers performance is still quite good and that aligns with what it ‘feels’ like during normal work - I never had reason to complain about performance.

But still there are some quite big ups and downs in the throughput graph. Maximum transfer speed looks good, but the minimum measured appears to be quite low. If anybody of you has a chance to run that benchmark on a new disk of the same or similar model I would be really interested to see the graph of that.

Running fstrim for the First Time

At first I enabled TRIM support for lvm and dmcrypt by setting issue_discards = 1 in /etc/lvm/lvm.conf and appending the discard option to crypttab. In order to have these changes go ‘live’, you also have to regenerate your initial ramdisk image (update-initramfs -u on Debian).

One reboot later I was ready to actually run fstrim:

# aptitude install util-linux
# fstrim -v /
/: 187978924032 bytes were trimmed

Took a few minutes, but actually finished faster than I thought, given that this was the first TRIM run ever. From looking at the number there was quite some work to do. Subsequent runs showed significantly smaller numbers in the range of Megabytes and finished in less than a second.

The Result

Clearly fstrim had a positive impact on the drive’s read performance. I think it’s quite interesting that the general shape of the throughput graph is still the same, with lows and highs in exactly the same places. But all the lows are on a higher level now, raising the minimum read rate to 240MB/s and the average to 495MB/s.

So that’s nice. However, considering this is after two years of never issuing a single TRIM command to the disk, I think it can be said that the built-in house keeping of this disk is doing a good job to keep performance up even without getting TRIM commands from the OS. Or maybe my usage pattern is just very SSD friendly.

Conclusion

At least some SSDs in some usage scenarios can be used for years without ever getting a single TRIM command at all, and not show any signs of performance degradation that you would notice during normal use.

Personally I will leave discard out of my fstab and stick to running fstrim manually whenever I think it’s necessary and I have a spare minute. Looking at the numbers I don’t think there will be much benefit in running it more often than twice a year, though.

In addition to potentially faster delete operations without discard, using fstrim will give you a clear error if TRIM for some reason doesn’t work at all (discard is ignored silently in this case), and you have the chance to do some potentially interesting before/after benchmarking to see if it has any effect or not.