Enabling and Testing SSD TRIM Support Under Linux

Rob Williams

Rob Williams

Editor-in-Chief
Staff member
Moderator
Owning an SSD that supports TRIM is great, but while Windows users have the benefit of having TRIM enabled for them, Linux users need to take the manual route - at least, at this point in time. In this article, we tackle the simple process of doing so, and also show how to verify that TRIM is indeed working as it should be.

You can check out our quick guide on enabling TRIM under Linux and then discuss it here!
 
F

feffer

Obliviot
Tried Rob's TRIM enable and test process. Works great! Initially, I made a silly mistake: though a supported kernel was booted, I saved the test file in "data" -- a spinning hdd mounted in /home. After I redid it from /opt (on the SSD) all worked as expected. Great job on this!

As expected enabling TRIM works on Linux Mint Debian Edition (LMDE) with kernel 2.6.38-2-amd64, but fails with Ubuntu 10.04 LTS and kernel 2.6.32-31-generic.

thx,
feffer
 
Last edited:
Rob Williams

Rob Williams

Editor-in-Chief
Staff member
Moderator
feffer said:
Tried Rob's TRIM enable and test process. Works great! Initially, I made a silly mistake: though a supported kernel was booted, I saved the test file in "data" -- a spinning hdd mounted in /home. After I redid it from /opt (on the SSD) all worked as expected. Great job on this!
Click to expand...

Haha! I am glad I'm not alone in making goofs like this. The other night, I booted into Ubuntu and tried chrooting into my Gentoo install, and everytime I did, I'd see the file system for the Ubuntu install. I was so confused and ended up rebooting multiple times to re-attempt it. Well, of course I was mounting the wrong partition, due to not thinking. Total *facepalm* moment there ;-)

From what I understand, full TRIM functionality (FS-wise) came to the kernel in 2.6.33, which is why it wouldn't have worked in the Ubuntu LTS. That part is unfortunate, but thankfully most distros today do in fact include the support.

Glad you go things working, and welcome to the forums! :D
 
B

brycenesbitt

Obliviot
Looks like you need an ext4 filesystem for discard to be supported. With ext3 I get:

root# mount /dev/sdc1 /boot -o noatime,discard
mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
root# cat /etc/motd
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)
Click to expand...

With an ext4 partition the operation is smooth:

mount /dev/sdc2 / -o remount,noatime,discard
Click to expand...
 
Rob Williams

Rob Williams

Editor-in-Chief
Staff member
Moderator
Welcome to the forums!

As mentioned in the article, ext4 is indeed required for TRIM to function, though there are other non-ext file systems that I believe will work as well (Brtfs, for one). TRIM is not possible on a swap partition, as its file system doesn't support it. On the upside, it's not too important since the speed gains would be just about nil. If you have a lot of RAM, the swap space likely won't even be accessed regardless. If the SSD you're using has built-in garbage collection, then that's at least something.
 
L

lynix

Obliviot
Reading sectors always returns zeroed bytes:

Code: 
[root@thor usr]$ hdparm --read-sector 271984 /dev/sdd

/dev/sdd:
reading sector 271984: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

Does the fact that the filesystem lies on an encrypted LVM volume matter for calculating the right sector numbers?
 
C

cocoonair

Guest
Great Article!

Thanks for your pleasant post. It's really a delight reading a simple straight forward "how to do" instead of scraping complicated peaces here and there out of the net. :)

I am running Debian stable and apparently the squeeze Kernel (2.6.32-5-amd64) supports TRIM. Not sure about that yet as I am quite a linux newbie and don't really know/want to upgrade the kernel... Running a Intel 320 here and would like to activate TRIM as it isn't working when test with a testfile and hdparn.

Any help appreciated! :)
 
B

bluesky

Obliviot
Should I be concerned that I do not return all 0's? My system returns all f's:

Code: 
# seq 1 1000 > testfile
# hdparm --fibmap testfile

testfile:
 filesystem blocksize 4096, begins at LBA 21792768; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0       -          -          -   
# sync
# hdparm --fibmap testfile

testfile:
 filesystem blocksize 4096, begins at LBA 21792768; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0  244354272  244354279          8
# hdparm --read-sector 244354272 /dev/sda

/dev/sda:
reading sector 244354272: succeeded
0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38
0a39 3031 310a 0a31 3231 310a 0a33 3431
310a 0a35 3631 310a 0a37 3831 310a 0a39
3032 320a 0a31 3232 320a 0a33 3432 320a
0a35 3632 320a 0a37 3832 320a 0a39 3033
330a 0a31 3233 330a 0a33 3433 330a 0a35
3633 330a 0a37 3833 330a 0a39 3034 340a
0a31 3234 340a 0a33 3434 340a 0a35 3634
340a 0a37 3834 340a 0a39 3035 350a 0a31
3235 350a 0a33 3435 350a 0a35 3635 350a
0a37 3835 350a 0a39 3036 360a 0a31 3236
360a 0a33 3436 360a 0a35 3636 360a 0a37
3836 360a 0a39 3037 370a 0a31 3237 370a
0a33 3437 370a 0a35 3637 370a 0a37 3837
370a 0a39 3038 380a 0a31 3238 380a 0a33
3438 380a 0a35 3638 380a 0a37 3838 380a
0a39 3039 390a 0a31 3239 390a 0a33 3439
390a 0a35 3639 390a 0a37 3839 390a 0a39
3031 0a30 3031 0a31 3031 0a32 3031 0a33
3031 0a34 3031 0a35 3031 0a36 3031 0a37
3031 0a38 3031 0a39 3131 0a30 3131 0a31
3131 0a32 3131 0a33 3131 0a34 3131 0a35
3131 0a36 3131 0a37 3131 0a38 3131 0a39
3231 0a30 3231 0a31 3231 0a32 3231 0a33
3231 0a34 3231 0a35 3231 0a36 3231 0a37
3231 0a38 3231 0a39 3331 0a30 3331 0a31
3331 0a32 3331 0a33 3331 0a34 3331 0a35
3331 0a36 3331 0a37 3331 0a38 3331 0a39
3431 0a30 3431 0a31 3431 0a32 3431 0a33
3431 0a34 3431 0a35 3431 0a36 3431 0a37
3431 0a38 3431 0a39 3531 0a30 3531 0a31
3531 0a32 3531 0a33 3531 0a34 3531 0a35

# rm testfile 
# sync
# hdparm --read-sector 244354272 /dev/sda

/dev/sda:
reading sector 244354272: succeeded
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
 
U

Unregistered

Guest
i am not sure if reading back is the way to go for testing. of course if it returns all 0s or all 1s (i.e. 0xFF) then trim works correctly, but AFAIK it might even work if this is not the case (after all, trimming does only tell the drive that we are no longer interested in a block, not that it should clear it. it might be easier for the firmware to just mark the data discardable in an internal table and return the old data instead of returning 0s/1s).
a better test is to look at the output of lsblk -D, this also would indicate which layers of the stack are the problem (in my case i am running ext4 on lvm on dmcrypt). also, ext4 prints an error (to dmesg) if it is mounted with the discard option but discards do not work correctly.
 
You must log in or register to reply here.
Top