How do you Know TRIM is Working With Your SSD in Your System?
October 2, 2011 1 Comment
Now that you have your shiny new SSD you want to take full advantage of it which can include TRIM support to improve performance. In this article I want to talk about how to tell if TRIM is working on your system (I’m assuming Linux of course).
Answering the question, “does TRIM work with my system?” is not as easy as it seems. The are several levels to this answer beginning with, “does my SSD support TRIM?”. Then we have to make sure the kernel supports TRIM. After that we need to make sure that the file system supports TRIM (or what is referred to as “discard”). If we’re using LVM (the device-mapper or dm layer) we have to make sure dm supports discards. And finally if we’re using software RAID (md: multi-device), we have to make sure that md supports discards. So answering the simple question, “does TRIM work with my system?” has a simple answer of “it depends upon your configuration” but it has a longer answer if you want details.
In the following sections I’ll talk about these various levels starting with the question of whether your SSD supports TRIM.
Does my SSD support TRIM?
While this is a seemingly easy question – it either works or it doesn’t – in actuality it can be something of a complicated question. The first thing to do with your distribution is to determine if your SSD supports TRIM, is to upgrade your hdparm package. The reason for this is that hdparm has fairly recently added some capability for enumerating if the hardware can support TRIM. As of the writing of this article, version 9.37 is the current version of hdparm. It’s pretty easy to build the code for yourself (in your user directory) or as root. If you look at the makefile you will see that by default hdparm is installed in /sbin. To install it locally just modify the makefile so that “binprefix” variable at the top, points to the base directory where you want to install it. For example, if I installed it in my home directory I would change binprefix to /home/laytonjb/binary (I install all applications in a subdirectory called “binary”). Then you simply do, ‘make’, ‘make install’ and you’re ready.
Once the updated hdparm is installed, you can test it on your SSD using the following command:
# /sbin/hdparm -I /dev/sdd
where /dev/sdd is the device corresponding to the SSD. If your SSD supports TRIM then you should see something like the following in the output somewhere:
* Data Set Management TRIM supported
I tested this on a SandForce 1222 SSD that I’ve recently been testing. Rather than stare at all of the output, I like to pipe the output through grep.
[root@test64 laytonjb]# /sbin/hdparm -I /dev/sdd | grep -i TRIM * Data Set Management TRIM supported (limit 1 block) * Deterministic read data after TRIM
Below in Figure 1 is a screenshot of the output (the top portion has been chopped off).
Figure 1: Screenshot of hdparm Output (Top section has been Chopped Off)
Does the kernel support TRIM?
This is one of the easier questions to answer in this article to some degree. However, I’ll walk through the details so you can determine if your kernel works with TRIM or not.
TRIM support is also called “discard” in the kernel. To understand what kernels support TRIM a small kernel history is in order:
- The initial support for discard was in the 2.6.28kernel
- In the 2.6.29kernel, swap was modified to use discard support in case people put their swap space on an SSD
- In kernel 2.6.30, the ability for the GFS2 file system to generate discard (TRIM) requests was added
- In the 2.6.32kernel, the btrfs file system obtained the ability to generate TRIM (discard) requests.
- In 2.6.33, believe it or not, the FAT file system got a “discard” mount option. But more importantly, in the 2.6.33 kernel, libata (i.e. the SATA driver library) added support for the TRIM command. So really at this point, kernels 2.6.33 and greater can support TRIM commands. Also, ext4 addedthe ability is used discard as a mount option for supporting the ability to use the TRIM command.
- In 2.6.36 ext4 added discard support when there is no journal using the “discard” mount option. Also, in 2.6.36 discard support for the delay, linear, mpath, and dm stripe targets were added to the dm layer. Support was also added for secure discard. NILFS2 got a “nodiscard”option since NILFS2 had discard capability when it was added to the kernel in 2.6.30 but no way to turn it off prior to this kernel version.
- In 2.6.37 ext4 gained the ability for batched discards. This was addedas an ioctl called FITRIM to the core code.
- In the 2.6.38 version, RAID-1 support of discard was added to the dm. Also, xfs added manual support for FITRIM, and ext3 added support for batched discards (FITRIM).
- In 2.6.39 xfs will add the ability to do batched discards.
So in general any kernel 2.6.33 or later should have TRIM capability in the kernel up to the point of the file system. This means the block device layer and the SATA library (libata) support TRIM.
However, you have to be very careful because I’m talking about the kernel.org kernels. Distributions will take patches from more recent kernels and back-port them to older kernels. So please check with your distribution if they are using a 2.6.32 or older kernel (before 2.6.33) but have TRIM support added to the SATA library. You might be in luck.
Does the file system support TRIM?
At this point we know if the hardware supports TRIM and if the kernel supports TRIM, but before it becomes usable we need to know if the file system can use the TRIM (discard) command. Again, this depends upon the kernel so I will summarize the kernel version and the file systems that are supported.
- 2.6.33: GFS2, nilfs2, btrfs, ext4, fat
- 2.6.33: GFS2, nilfs2, btrfs, ext4 (including no journal mode), fat
- 2.6.37: GFS2, nilfs2, btrfs, ext4 (including no journal mode and batched discard), fat
- 2.6.38: GFS2, nilfs2, btrfs, ext4 (including no journal mode and batched discard), fat, xfs, ext3
So if you have hardware that supports TRIM, a kernel that supports TRIM, then you can look up if your file system is capable of issuing TRIM commands (even batched TRIM).
Does the dm layer support TRIM?
The dm layer (device mapper) is a very important layer in Linux. You probably encounter this layer when you are using LVM with your distribution. So if you want to use LVM with your SSD(s), then you need to make sure that the TRIM command is honored starting at the top with the file system, then down to the dm layer, then down to the the block layer, then down to the driver layer (libata), and finally down to the drives (hardware). The good news is that in the 2.6.36 kernel, discard support was added to the dm layer! So any kernel 2.6.36 or later will support TRIM.
Does the MD layer support TRIM?
The last aspect we’ll examine is support of software RAID via MD (multi-device) in Linux. However, I have some bad news that currently TRIM is not really supported in the md layer (yet). So if you’re using md for software RAID within Linux, the TRIM command is not supported at this time.
Testing for TRIM Support
The last thing I want to mention is how you can test your system for TRIM support beyond just looking at the previous lists to see if TRIM support is there. I used the procedure in this article to test if TRIM was actually working.
The first logical step is to make sure the SSD isn’t being used during these tests (i.e. it’s quiet). Also be sure that the SSD supports TRIM using hdparm as previously mentioned (I’m using a SandForce 1222 based SSD that I’ve written about previously). Also be sure your file system uses TRIM. For this article I used ext4 and mounted it with the “discard” option as show in Figure 2 below.
Figure 2: Screenshot of /etc/fstab File Showing discard mount option
Then, as root, create a file on the SSD drive. The command is,
[root@test64 laytonjb]# cd /dev/sdd [root@test64 laytonjb]# dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct
Below in Figure 3 is the screenshot of this on my test system.
Figure 3: Screenshot of first command
The next step is to get the device sector of the tempfile just created and copy the first sector information after value 0. It sounds like a mouth full but it isn’t hard. The basic command is,
[root@test64 laytonjb]# /sbin/hdparm --fibmap tempfile
Below in Figure 4 is the screenshot of this on my test system.
Figure 4: Screenshot of Sector Information for Temporary File
So the beginning LBA for this file that we are interested in, is at sector 271360.
We can read that sector of the file using this location to show that there is data written there. The basic command is,
[root@test64 laytonjb]# /sbin/hdparm --read-sector 271360 /dev/sdb
Below in Figure 5 is the screenshot of this on my test system.
Figure 5: Screenshot of Sector Information for Temporary File
Since the data is not all zeros, that means there is data there.
The next step is to erase the file, tempfile, and sync the system to make sure that the file is actually erased. Figure 6 below illustrates this.
Figure 6: Screenshot of Erasing Temporary File and Syncing the Drive
I ran the sync command three times just to be sure (I guess this shows my age since the urban legend was to always run sync several times to flush all buffers).
Finally, we can repeat reading the sector 271360 to see what happened to the data there.
[root@test64 laytonjb]# /sbin/hddparm --read-sector 271360 /dev/sdb
Below in Figure 7 is the screenshot of this on my test system.
Figure 7: Screenshot of Sector Information for Temporary File After File was Erased
Since the data in that sector is now a bunch of zeros, you can see that the drive has “trimmed” the data. This requires a little more explanation.
Before the TRIM command existed, the SSD wouldn’t necessarily erase the block right away if the data is erased. The next time it needed the block it would erase it prior to using it. This means that the file deletion performance is very good since the SSD just marked the block as empty and returned to the kernel. However, the next time that block was used, it first had to be erased, potentially slowing down the write performance.
Alternatively, the block could be erased when the data was deleted but this means that the file delete performance isn’t very good. However, this can help write performance because the blocks are always erased and ready to be used.
TRIM offers the opportunity for the operating system (file system) to tell the SSD that it is done with the block even if the SSD isn’t sure the block isn’t being used. So when the SSD receives a trim command, it marks the block as empty and when it gets a chance, when the SSD perhaps isn’t as busy, it will erase the empty blocks (i.e. “trim” them or “discard” their contents). This means that the “erase” cycle isn’t affecting write performance or file delete performance, improving the apparent overall performance. This sounds great and this usually works really well for desktops where we can take a break periodically so the SSD has time to erase trimmed blocks. However, if the SSD is being used quite a bit, then the SSD may not have an opportunity to erase the blocks so we’re back to the behavior without TRIM. This isn’t necessarily a bad thing, but just a limitation of what TRIM can do for SSD performance.
I hope you have found this article useful. It is a little convoluted in answering the question “does my Linux box support TRIM”? Unfortunately, the answer isn’t simple and you have to step through all of the layers to fully understand if TRIM is supported. A good way to start is to look at the last list about which file systems support TRIM, select the one you like, and see which kernel version you need. If you need dm support for LVM then you have to use at least 2.6.36. If you use MD with your SSDs then I’m afraid you are out of luck with TRIM support.