惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
云风的 BLOG
云风的 BLOG
小众软件
小众软件
雷峰网
雷峰网
博
博客园 - 【当耐特】
V
V2EX
WordPress大学
WordPress大学
IT之家
IT之家
Last Week in AI
Last Week in AI
罗
罗磊的独立博客
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Apple Machine Learning Research
Apple Machine Learning Research
钛媒体：引领未来商业与生活新知
钛媒体：引领未来商业与生活新知
V
Visual Studio Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
The Cloudflare Blog
Jina AI
Jina AI
博
博客园 - 司徒正美
阮一峰的网络日志
阮一峰的网络日志
博
博客园 - 聂微东
大猫的无限游戏
大猫的无限游戏
博
博客园 - 三生石上(FineUI控件)
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Stop Letting SSD Performance Rot: Practical `fstrim.timer...
Lyra · 2026-05-07 · via DEV Community

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

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。