The SSD’s internal “garbage collecting” processes are responsible for erasing blocks and managing wear leveling. However, filesystems typically “delete” data by just marking it in their own records as space that is available again. They do not actually erase the data from the underlying storage, but may overwrite the area previously occupied by that data on subsequent writes.
This means that the SSD will typically not know that a page is no longer needed until it receives instructions from the filesystem to write to the same logical location at a later time. It cannot perform its garbage collection routines because it is never informed when data is deleted, just when the space previously reserved for it should now be used for other data.
The TRIM command propagates information about which data is no longer being used from the filesystem down to the SSD. This allows the device to perform its regular garbage collecting duties when idle, in order to ensure that there are zeroed pages ready to handle new writes. The SSD can shuffle data ahead of time, clean up stale pages, and generally keep the device in good working condition.
Performing TRIM on every deletion can be costly, however, and can have a negative impact on the performance of the drive. Configuring periodic TRIM gives the device bulk information about unneeded pages on a regular schedule instead of with each operation.
In this tutorial, you will learn how SSDs and TRIM work and then enable periodic TRIM on a variety of Linux distributions.
You’ll enable periodic TRIM on three different Linux distributions in this tutorial, Ubuntu 22.04, Debian 11, and CentOS 8. Using the following guides to set up these distributions with a non-root user.
To better understand the problems that TRIM solves, it helps to know a few things about how SSDs store and manage their data.
Data on SSDs is written and read in units of a fixed size known as pages. Pages, in turn, are grouped together in larger units called blocks.
SSDs can read and write to pages individually. However, they can only erase data at the block level. Another limitation is that writes can only be performed on pages that have been completely zeroed (all bits set to 0). This means that overwriting data directly is impossible.
To modify data, the SSD actually has to read the information from the old location, modify it in memory, and then write the modified data to new, zeroed pages. It then updates an internal table to map the logical location that the operating system is given to the new physical location of the data on the device. The old location is marked in a different internal table as stale: not in use, but not yet zeroed.
To reclaim the stale pages, the SSD’s internal garbage collecting processes must read all of the valid pages from a block and write them to a new block. Again, the internal table mapping logical and physical locations is updated. The old block, which now contains no unique, still-in-use data can then be zeroed and marked as ready for future writes.
You may have already enabled continuous TRIM on your devices when they were mounted. Some servers or mounted disks may be automatically configured with continuous TRIM. Before you enable periodic TRIM, it makes sense to take a look at your current mount options.
Continuous TRIM is enabled by mounting a drive or partition with the
First, find the filesystems that are currently mounted with the
- findmnt -O discard
OutputTARGET SOURCE FSTYPE OPTIONS /mnt/data /dev/sda1 ext4 rw,relatime,discard,data=ordered /mnt/data2 /dev/sdb1 ext4 rw,relatime,discard,data=ordered
You can remount these file systems in place, without the
discard option, by including
-o remount,nodiscard with
- sudo mount -o remount,nodiscard /mnt/data
- sudo mount -o remount,nodiscard /mnt/data2
If you run the
findmnt command again, you should receive no results:
- findmnt -O discard
nano or your favorite text editor, open the
/etc/fstab file to see the mount options currently defined for your filesystems. These determine how the filesystems are mounted each boot:
- sudo nano /etc/fstab
Look for the
discard option and remove it from lines that you find:
. . . # /dev/sda1 /mnt/data ext4 defaults,nofail,discard 0 0 /dev/sda1 /mnt/data ext4 defaults,nofail 0 0 # /dev/sdb1 /mnt/data2 ext4 defaults,nofail,discard 0 0 /dev/sdb1 /mnt/data2 ext4 defaults,nofail 0 0
Save and close the file when you are finished. If you are using
Ctrl+X, then when prompted,
Y and then Enter. The filesystems will now be mounted without the
discard option, and will mount in this same way on subsequent boots. We can now set up periodic TRIM for all filesystems that support it.
Ubuntu 22.04 ships with a script that is run weekly by
cron. This means that enabling the
systemd method described in the following section is unnecessary for Ubuntu 22.04.
To view the script, use
- cat /etc/cron.weekly/fstrim
Output#!/bin/sh # trim all mounted file systems which support it /sbin/fstrim --all || true
As you can see, this script needs a version of
fstrim with the
--all flag. Many versions of 'fstrim` shipped with earlier releases of Ubuntu do not contain this option.
systemd distributions, periodic TRIM can be enabled with the
fstrim.timer file, which will run TRIM operations on all capable, mounted drives once a week. This also leverages the
fstrim --all option.
At the time of this writing, this is the best method for the following distributions and up:
For CentOS and Fedora, the
fstrim.timer units are available by default. To schedule a weekly TRIM of all attached capable drives, enable the
- sudo systemctl enable fstrim.timer
Your server should now TRIM all mounted filesystems that support the operation, once weekly.
Your Linux server should now be configured to periodically TRIM all supported filesystems on a weekly basis. TRIM helps to maximize both the long term performance and lifespan of your SSDs.
Continuous TRIM operations may sound ideal, but they can add significant overhead to regular file system operations. Periodic TRIM offers a good middle ground by relaying key information needed to perform routine maintenance of the drive in a scheduled job instead of as a component of each file operation. Check out our article on Storage Terminology and Concepts in Linux to learn more about this topic.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in our Questions & Answers section, find tutorials and tools that will help you grow as a developer and scale your project or business, and subscribe to topics of interest.Sign up now
DigitalOcean Block Storage allows you to attach additional storage volumes to your Droplets quickly and easily. Block Storage volumes function like regular block devices when attached to your servers, allowing you to use familiar tools to manage your storage needs. In this series, we will introduce basic Linux storage terminology, cover how to create and manage Block Storage volumes, and how to perform a variety of administrative tasks to keep your volumes running smoothly.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Super helpful. Statically compiling a newer fstrim is a great idea in certain edge cases where you can’t replace an antiquated OS.
Great tutorial! Thank you.
One n00b question: Is there a way to test that this newer version of fstrim is actually working?
Well written :-) But can you elaborate on the discard feature of a device, which you can see using e.g. " lsblk -d -o name,DISC-GRAN,DISC-MAX,model"
What’s going on when a disk support discard?
And when you call the “fstrim -a” how does the disk know which block has been deleted, where is this information stored?
Awesome Tutorial Thanks Mark
Thanks for this tutorial! Never had a clue about this. Luckily I was running 16.04 so this was very easy to implement :)