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

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

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

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

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

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

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

On this machine, the service executes:

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

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

Then confirm:

systemctl status fstrim.timer
systemctl list-timers --all fstrim.timer

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

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

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"

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

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

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

fstrim(8) man page: https://man7.org/linux/man-pages/man8/fstrim.8.html
systemd fstrim.timer manual: https://www.freedesktop.org/software/systemd/man/latest/fstrim.timer.html
Fedora change note on enabling fstrim.timer: https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
lsblk(8) man page: https://man7.org/linux/man-pages/man8/lsblk.8.html
findmnt(8) man page: https://man7.org/linux/man-pages/man8/findmnt.8.html

推荐订阅源

DEV Community