Enabling and Testing SSD TRIM Support Under Linux

[PAGETITLE=Introduction][Top Ad] With the launch of Windows 7 in the fall of 2009, adopters were treated to many useful new features. But for SSD users, there was one that mattered more than the others: TRIM support. Being a full-time Linux user, I couldn't help but feel a bit left out. So I had to investigate, and see just what it took to enjoy the benefits of TRIM under my preferred OS. For those unaware, TRIM is an ATA command that solid-state drives can take advantage of in order to prolong its fast performance as time passes on. SSDs that don't support TRIM have an inherent fault of slowing down over long periods of time (months, or years depending on the level of usage). With TRIM, however, affected blocks are wiped clean after a file deletion, resulting in performance that matches the drive's original specs as much as possible. In the months that followed the Windows 7 launch, it seemed as though exploiting TRIM under Linux was impossible, despite official support being found in the kernel beginning in December 2008. Since that time, though, things have been improved quite a bit. We've gone from TRIM being impossible to exploit, to it being an arduous chore to exploit, to having automatic support that's simple to enable. For those wanting to enable TRIM support, it's recommended that the most up-to-date kernel (at least 2.6.33) is used, and also the ext4 file system. While other file systems might be supported (I'd love to hear about them if so), ext4 is a great choice and is likely what you're already using. Enabling TRIM Support. While Windows 7 users have the benefit of having TRIM enabled by default, as long as a supported SSD is present, I don't believe any current Linux distribution does the same. Yes, the process does require the command-line, but don't fret - even a novice user can handle this! Enabling TRIM is as simple as adding the word 'discard' next to the proper drive in your /etc/fstab file, but to pull that off, we'll need to find the proper /dev/sdX or UUID value for it. Depending on the Linux distro being used, it could be one or the other. To get started, open a command-line (terminal) and type in 'cat /etc/fstab'. You'll see a result like this: /dev/sda5 /boot ext2 noauto,noatime 1 2 /dev/sda7 / ext4 noatime,discard 0 1 /dev/sda6 none swap sw 0 0 /dev/sr0 /mnt/cdrom auto noauto,user 0 0 UUID=04D40DB9D40DADCC /mnt/storage ntfs-3g defaults,rw,owner,uid=1000,gid=100 UUID=347240AF7240781E /mnt/storagetwo ntfs-3g defaults,rw,owner,uid=1000,gid=100 UUID=11f92990-b2e0-4a7c-a9b7-98d1b0bb4df5 /mnt/storagethree ext4 noatime,discard 0 1 I have bolded two entries in the fstab above that have TRIM ('discard') enabled; one using the /dev/sdX differentiator, and the other using a UUID. The OS drive I'm using is /dev/sda, and its root partition is /dev/sda7 - hence, that's the entry in the /etc/fstab that should have 'discard' next to it. The drive I am using for testing is UUID=11f92990-b2e0-4a7c-a9b7-98d1b0bb4df5, and again, 'discard' is placed next to it as well. Most distros will not mix and match drive identifiers like this; I am just doing it for the sake of the example. If you have more than one ext4 partition on your SSD, you can feel free to add 'discard' to each one of the related entries. If your distro uses only UUIDs to differentiate the drives, and you're not sure which of those correspond to your SSD, you can open up a command-line and type in ' ls -l /dev/disk/by-uuid/ ' which will tell you which UUIDs belong to which drive and partition. You can then use a tool such as "Disk Utility" or "GParted" to discover which /dev/sdX entry is the correct partition, and then use that gained knowledge to understand which entry in the /etc/fstab to add 'discard' to. To edit the /etc/fstab file in order to add 'discard' to one of the entries, a command-line will again be needed, along with root (su) or sudo. In distributions that support sudo, you can type in ' sudo nano -w /etc/fstab ' and then type in your password; if sudo support doesn't exist, enter root with ' su ' and then type in ' nano -w /etc/fstab '. Here, use the arrow keys to move the 'cursor' to the proper location, and then, as seen in the picture, make sure that the word 'discard', without quotes, is among the other options for the drive. The only thing you are doing here is adding 'discard' - please do not change other values unless you understand what the result will be. Once done, hit Ctrl + X to quit, then "y" + "Enter" to save. Changes will not be immediate, as the drive needs to be remounted, in most cases requiring a reboot. After rebooting, you can open another command-line and type in 'mount', where you'll see a result like this: /dev/sda7 on / type ext4 (rw,noatime,discard,commit=0) If 'discard' is listed next to the drive, it's enabled. On the next page, we'll take a quick look at how to find out if TRIM is working as it should be, using hdparm. [PAGEBREAK][PAGETITLE=Checking for TRIM Success; Final Thoughts][Top Ad] If the SSD in question does in fact support TRIM, and 'discard' is properly added to the /etc/fstab file, then it can be assumed that TRIM is in fact working. But for assurance, there's a simple test that can be performed, though it does require a little more effort in the command-line than enabling TRIM in the first place did. Because TRIM purges all data found in affected 'sectors' after a file is deleted, the result should be sectors that read a bunch of 0s, not some sort of data. On a non-TRIM drive, data found in a sector would remain the same even after the file is deleted, which is the reason performance can find itself degraded over time. With TRIM purging out the data properly, any new writes to the drive will target clean, like-new sectors. For testing, we'll have to create a small file on the affected SSD partition, as we'll be deleting it to see if TRIM in fact worked. After opening up a command-line, enter su or sudo mode (the latter using ' sudo -s '). Then, create a small file: techgage Desktop # seq 1 1000 > testfile That command creates a simple text file with numbers ranging from 1 to 1000, and in total, it weighs in at about 4KB (a typical sector size). With that file created, it's time to find out which sector(s) on the drive it's using: techgage Desktop # hdparm --fibmap testfile You will see this sort of result: Take note of the first 'begin_LBA' value, which in this case is 49598792. That's the beginning sector for the file, and one we can read from for this test. With the sector number in hand, we can check for its contents using these commands: techgage Desktop # sync techgage Desktop # hdparm --read-sector 49598792 /dev/sda (If your drive is not /dev/sda, replace it with the correct value.) The 'sync' command must be run prior to the hdparm one for the sake of flushing out the file system buffer, and once run, the hdparm command will show all of the contents of the given sector in hexadecimal format. Time to delete the file, and then run the same commands as before: techgage Desktop # rm testfile techgage Desktop # sync techgage Desktop # hdparm --read-sector 49598792 /dev/sda That's just what we wanted to see... nothing! If all 0s appear, then TRIM worked, but if the same data as before is still there, be sure that the "sync' command was in fact run, as it should be in order to flush out the buffer and give you accurate information. Final Thoughts. It took a little while after Windows 7's launch for robust support of TRIM to hit Linux, but it's here, and as you can see, enabling and testing for it couldn't be much simpler. Had I known that enabling it was as simple as adding 'discard' to the /etc/fstab file, I would have upgraded to an SSD months ago! And since we're able to use hdparm to actually check to see that TRIM is in fact working, there's no doubt left in our minds that once setup, TRIM will keep our SSDs in tip-top shape. Although a rather simple article, I wanted to get the method out there and explain in as easy terms as possible how to get things done. If any of this guide proved a little confusing, or more information would be desired, please feel free to post in our related thread below, and we'll consider updating the article. Discuss this article in our forums! Have a comment you wish to make on this article? Recommendations? Criticism? Feel free to head over to our related thread and put your words to our virtual paper! There is no requirement to register in order to respond to these threads, but it sure doesn't hurt!

Enabling and Testing SSD TRIM Support Under Linux

Page 271 –

Rob Williams