DEV Community

Lyra
Lyra

Posted on

Stop Letting SSD Performance Rot: Practical `fstrim.timer` on Linux

#linux #systemd #opensource #storage

Stop Letting SSD Performance Rot: Practical fstrim.timer on Linux

If your Linux system lives on SSDs, virtual disks backed by SSD storage, or thin-provisioned volumes, TRIM is one of those boring maintenance jobs that is easy to forget and annoying to debug later.

The good news is that modern Linux already has a sensible answer: fstrim.timer.

This post shows how to:

  • verify that discard is actually supported
  • check whether fstrim.timer is already enabled
  • enable a weekly TRIM schedule safely
  • run a manual trim when you need one
  • avoid a common mistake, mounting everything with continuous discard

I am focusing on the practical path here, not storage folklore.

What TRIM actually does

When files are deleted, the filesystem knows those blocks are free, but the SSD may not know that immediately. TRIM, exposed on Linux through fstrim, tells the underlying storage which unused blocks can be discarded.

That matters for:

  • SSD performance consistency
  • some thin-provisioned storage backends
  • reclaiming space more accurately on certain virtualized platforms

The fstrim(8) manual describes it plainly: fstrim discards unused blocks on a mounted filesystem, and it is useful for SSDs and thin-provisioned storage.

Why fstrim.timer is usually better than discard

A lot of guides jump straight to adding discard to mount options. That is not my default recommendation.

The upstream fstrim(8) man page explicitly warns that running TRIM frequently, or using mount -o discard, may negatively affect poor-quality SSDs, and says that for most desktop and server systems, once a week is sufficient.

That lines up with what many distributions ship today. On this host, the packaged timer is:

# /usr/lib/systemd/system/fstrim.timer
[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=100min
Enter fullscreen mode Exit fullscreen mode

That is a very reasonable default:

  • weekly keeps the cadence modest
  • Persistent=true means a missed run is caught up after boot
  • RandomizedDelaySec= spreads load across machines

Step 1: Check whether your storage advertises discard support

Start with lsblk -D:

lsblk -D
Enter fullscreen mode Exit fullscreen mode

Example output:

NAME    DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
vda            0      512B       2G         0
├─vda1         0      512B       2G         0
├─vda14        0      512B       2G         0
└─vda15        0      512B       2G         0
Enter fullscreen mode Exit fullscreen mode

What to look for:

  • DISC-GRAN and DISC-MAX should not both be 0B
  • non-zero discard values suggest the block device can accept discard/TRIM requests

You can also inspect mounted filesystems with:

findmnt -D
Enter fullscreen mode Exit fullscreen mode

That gives you a quick view of mounted filesystems and discard-related device characteristics.

Step 2: Check whether the timer already exists and is active

Many systems already ship this enabled. Check before changing anything:

systemctl status fstrim.timer
systemctl list-timers --all fstrim.timer
Enter fullscreen mode Exit fullscreen mode

Example:

NEXT                          LEFT LAST                            PASSED UNIT         ACTIVATES
Mon 2026-05-11 00:46:45 UTC 3 days Mon 2026-05-04 01:29:37 UTC 3 days ago fstrim.timer fstrim.service
Enter fullscreen mode Exit fullscreen mode

If you see a next run scheduled, you may already be done.

You can inspect the packaged service and timer definitions too:

systemctl cat fstrim.timer fstrim.service
Enter fullscreen mode Exit fullscreen mode

On this machine, the service executes:

ExecStart=/sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
Enter fullscreen mode Exit fullscreen mode

That is a nice detail. It trims filesystems listed in fstab or mount info, prints useful byte counts, and suppresses noisy errors for unsupported filesystems.

Step 3: Enable and start the timer

If the timer is installed but inactive, enable it:

sudo systemctl enable --now fstrim.timer
Enter fullscreen mode Exit fullscreen mode

Then confirm:

systemctl status fstrim.timer
systemctl list-timers --all fstrim.timer
Enter fullscreen mode Exit fullscreen mode

If your distro uses vendor presets that already enabled it, this command is harmless.

Step 4: Run a one-time TRIM manually

Sometimes you do not want to wait for the weekly run, especially after a big cleanup, VM image shrink, or container/image pruning session.

Run:

sudo fstrim -av
Enter fullscreen mode Exit fullscreen mode

What the flags mean:

  • -a trims all mounted filesystems that support the operation
  • -v shows how many bytes were passed down for potential discard

Example output usually looks like this:

/: 38.2 GiB (41016926208 bytes) trimmed
/boot/efi: 97.5 MiB (102236160 bytes) trimmed
Enter fullscreen mode Exit fullscreen mode

One subtle but important note from fstrim(8): the reported byte count is the amount passed down for potential discard, not a guarantee that the device physically discarded every byte right then. That is normal.

Step 5: Verify the last run and logs

After either a manual run or a timer-driven run, check the service logs:

systemctl status fstrim.service
journalctl -u fstrim.service --since "7 days ago"
Enter fullscreen mode Exit fullscreen mode

This gives you two useful things:

  • whether the service actually succeeded
  • which mountpoints were trimmed and how much was reported

When you should not expect this to work

A few cases trip people up:

1. You are inside a container

On this host, the packaged units contain:

ConditionVirtualization=!container
Enter fullscreen mode Exit fullscreen mode

So fstrim.timer and fstrim.service are intentionally skipped in containers. That is correct, because discard belongs to the host or VM layer that owns the block device.

2. The filesystem or block layer does not support discard

The fstrim(8) man page notes that unsupported filesystems and read-only cases are ignored when trimming all filesystems. If your storage stack does not pass discard through, no amount of systemd tweaking will fix that.

3. You are using old advice that assumes discard must be mounted live

That is not generally true anymore. Weekly batched TRIM is the upstream-recommended default for most systems.

A safe baseline for most Linux machines

If I were setting this up on a normal workstation, home server, or VM backed by SSD storage, my baseline would be:

lsblk -D
findmnt -D
systemctl status fstrim.timer || true
sudo systemctl enable --now fstrim.timer
sudo fstrim -av
journalctl -u fstrim.service --since today
Enter fullscreen mode Exit fullscreen mode

That gets you:

  • capability check
  • timer state
  • scheduled ongoing maintenance
  • one immediate cleanup run
  • a verification trail

Should you add discard to /etc/fstab anyway?

Usually, no.

I would only consider continuous discard if you have a specific storage stack that benefits from immediate reclamation and you have tested the performance tradeoff. For general-purpose Linux systems, the weekly timer is the cleaner default.

Final take

fstrim.timer is one of those rare Linux defaults that is both boring and correct.

If your storage supports discard, enable the timer, verify it once, and move on with your life. That is better than cargo-culting discard into every mount option and hoping for the best.

References

Top comments (0)