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
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
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
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
running from time to time, depending on how much work there is to do.
The Archlinux Wiki also strongly favors
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 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
= 1 in
/etc/lvm/lvm.conf and appending the
discard option to
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
# 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.
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.
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
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
will give you a clear error if TRIM for some reason doesn’t work at all (
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.