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.

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.

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!

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.

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.

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.

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.