#fstrim

jarnhandr@diaspora.glasswings.com

To fstrim, or not to fstrim?

It's been long advised when running Linux on SSDs that you should regularly run /sbin/fstrim to deallocate deleted blocks on the SSDs, to improve wear life and performance. However, if you've tried that lately, you've probably seen the following error message:

fstrim: /: discard not supported

And researching this will lead you down a rabbithole of confusing stale information as to where and when and in what combinations of software it is supported, and dubious workarounds like breaking an array, running fstrim on the raw devices, then reassembling the array.

If you put all the pieces together, what you'll eventually find is that discard SHOULD be supported on all CURRENT versions of MDRAID, LVM, LUKS, whatever you're using, and passed through to the underlying device.

But this is a red herring. Because the simple fact is, unless you're using some cheap bottom-of-the-bargain-bin SSD, you don't need to worry about any of this any more, thanks to something called active garbage collection. It is supported by virtually all modern SSDs, as part of wear leveling functionality, and what it fundamentally means is that when idle the device does its own fstrim — or something equivalent — internally.

So the short answer to "How can I make fstrim work without this error?" is, "Don't." The drive knows what it's doing and already has the issue well in hand. Just get out of its way and leave it to it.

(However, for performance reasons, you SHOULD still set your kernel IO scheduling algorithm to NOOP (none) by appending elevator=noop to the kernel command line in your grub configuration.)

#linux #computers #ssd #fstrim