Enabling and Testing SSD TRIM Support Under Linux

Discussion in 'Reviews and Articles (Archived)' started by Rob Williams, May 5, 2011.

  1. Rob Williams

    Rob Williams Editor-in-Chief Staff Member Moderator

    12,080
    1
    Jan 12, 2005
    Atlantic Canada
    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!
     
  2. feffer

    feffer Obliviot

    1
    0
    May 21, 2011
    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: May 21, 2011
  3. Rob Williams

    Rob Williams Editor-in-Chief Staff Member Moderator

    12,080
    1
    Jan 12, 2005
    Atlantic Canada
    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
     
  4. brycenesbitt

    brycenesbitt Obliviot

    2
    0
    Jun 13, 2011
    Looks like you need an ext4 filesystem for discard to be supported. With ext3 I get:

    With an ext4 partition the operation is smooth:

     
  5. brycenesbitt

    brycenesbitt Obliviot

    2
    0
    Jun 13, 2011
    An issue to consider: is there a way to enable TRIM support on Linux swap partitions (type 82 in fdisk)?
     
  6. Rob Williams

    Rob Williams Editor-in-Chief Staff Member Moderator

    12,080
    1
    Jan 12, 2005
    Atlantic Canada
    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.
     
  7. lynix

    lynix Obliviot

    1
    0
    Nov 9, 2011
    Reading sectors always returns zeroed bytes:

    Code:
    [[email protected] 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?
     
  8. cocoonair

    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! :)
     
  9. bluesky

    bluesky Obliviot

    1
    0
    Nov 19, 2012
    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
     
  10. Unregistered

    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.
     

Share This Page