SSD Trim on Archlinux

Question

I heard a lot of different opinions about SSD Trim and normally it's not very important to know how that is handled because you know that is handled unless I use systems where most of the installation steps are manual like Arch Linux.

The Arch Linux documentation does explain few ways to configure SSD Trimming, continuous, periodic... etc. but it does not say if the kernel is doing trimming by default on a supported filesystem without any additional configuration step.

Can I safely skip manual configuration of continuous or periodic trim found in the documentation? How do I monitor those kind of operations? Would I be safe on a clean installation using a kernel 5+ and ext4 as fs without using any of those approaches explained on the documentation?

(https://wiki.archlinux.org/index.php/Solid_state_drive)?

Should I be worried in the long term because I never trimmed an SSD disk when Arch Linux silently pretended to be healthy for so long?

Answer 1

The kernel only issues the discard operation in two occassions:

1. Periodically: When the fstrim tool asks it to.

2. Continuously: Whenever files are deleted, if the filesystem was mounted with the discard option. This option is disabled by default.

The second option has usually been avoided because it is synchronous – most filesystems wait every time until discard is complete, which makes syncing writes to disk rather slow as discard is not exactly a fast operation. (Asynchronous discard is only present in XFS and very recently in Btrfs.) I would also imagine unnecessarily frequent discard operations don't help the SSD lifetime much, either.

(Even more so, you can see a notice in your linked article that a few older SATA-based SSDs didn't support "queued" TRIM, which meant all operations – even reads – must wait until the TRIM request finishes its job.)

For that reason, most systems instead choose the first option and schedule fstrim -Av every week or so. This is often done using the "fstrim.timer" systemd unit. The fstrim service will write to syslog every time it's invoked:

$ journalctl -u fstrim

Feb 07 19:18:23 fstrim[401]: /: 484.5 GiB (520173604864 bytes) trimmed on /dev/sdb3

---

Your SSD won't burst into flames if you choose to not use TRIM at all (even if it's manufactured by Samsung); it will only become somewhat slower at accepting writes once it thinks that 100% of the disk is in use.

(That said, new SSDs seem to have enough spare space to continue working fine even if TRIM is never used, but I haven't done or sought any research into how this affects their performance, it's just my general guess.)

Note that if you're using LVM or cryptsetup, all such layers need to be configured to pass through the discard operation to the lower layer. By default, cryptsetup ignores discard operations as it prioritizes privacy over performance – TRIM by its nature reveals which disk areas are in use and which ones are free.