The Problem with SSDs and Deleted Files
Unlike traditional mechanical hard drives (HDDs) that can easily overwrite old data with new data, Solid State Drives (SSDs) operate on flash memory cells. Before an SSD can write new data to a sector that previously held a deleted file, it must physically erase the block first. This read-erase-modify-write cycle causes a severe performance penalty known as “write amplification.”
When you delete a file in Linux, the operating system simply marks the filesystem pointer as available; it does not inform the SSD hardware that the underlying flash cells can be wiped. Over time, as the drive fills up, the SSD controller assumes the drive is completely full of valid data, dramatically slowing down write speeds and accelerating hardware degradation.
The Solution: The TRIM Command
The TRIM command (implemented in Linux as fstrim) bridges this gap. It allows the Linux kernel to send a batch notification to the SSD controller, explicitly telling it which data blocks are no longer in use by the filesystem. The SSD can then perform its internal garbage collection in the background, wiping those cells and restoring the drive to factory-like write speeds.
Why You Shouldn’t Use Continuous TRIM (discard)
Historically, Linux administrators enabled “continuous TRIM” by adding the discard mount option to their /etc/fstab file. This forced the system to send a TRIM command to the SSD every single time a file was deleted.
This is generally considered a bad practice today. Continuous TRIM causes severe performance bottlenecks during large file deletions (like removing an old kernel or deleting a massive log directory) because the filesystem has to pause and wait for the SSD controller to acknowledge the TRIM commands.
Setting Up Periodic TRIM via systemd
The modern, recommended approach is “periodic TRIM.” Instead of trimming on every deletion, you run the fstrim command once a week. This allows the SSD to perform garbage collection during low-usage hours without impacting real-time performance.
Most modern Linux distributions (including Ubuntu, Debian, Fedora, and Arch) use systemd, which includes a built-in, highly optimized timer specifically for this task.
Step 1: Verify SSD TRIM Support
Before enabling the timer, ensure your drive actually supports the TRIM operation. Run the following command:
lsblk -DLook at the DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. If the values are greater than zero (e.g., 512B and 2G), your drive supports TRIM. If the values are 0B, the drive does not support it, or your USB enclosure is blocking the command.
Step 2: Enable the fstrim.timer
You do not need to write a custom cron job. Systemd provides the fstrim.timer unit out of the box. To enable and start it immediately, run:
sudo systemctl enable --now fstrim.timerStep 3: Verify the Timer Status
To confirm that the timer is active and to see when it is next scheduled to run, execute:
systemctl list-timers | grep fstrimBy default, the fstrim.timer is configured to run at midnight every Monday. When it triggers, it executes the fstrim.service, which runs the command /sbin/fstrim --fstab --verbose --quiet-unsupported.
Conclusion
By enabling the periodic fstrim.timer instead of using the outdated discard mount option, you strike the perfect balance between maximizing SSD performance, prolonging the lifespan of your flash storage, and ensuring your Linux server remains highly responsive during heavy I/O operations.