Does Ubuntu have support for the TRIM command for use with SSD?
772
SSD drives need to be "cleared/reset" after the drive fills up to maintain performance. This is done through the TRIM command for new SSD drives. Does Ubuntu support the TRIM command (through hdparm etc) for clearing/resetting of these drives?
Also, the TRIM stuff happens automatically - empty blocks are automatically released when they're no longer needed (eg, you delete a file), if the disk reports that it supports TRIM. You don't have to manually issue a hdparm command for this to work.
Jeremy's answer is not entirely accurate AFAIK. I've been running the latest stable kernels on Lucid for some time now and have been following the status of TRIM quite keenly as I have an OCZ Agility as my main disk.
Here's what (I think) I know:
The kernel has TRIM support as of 2.6.33 (Maverick is 2.6.35).
EXT4 has TRIM support but only when journaling is turned off.
The way TRIM works in the kernel is very basic and quite slow. Disks following the specs can accept multiple ranges but the kernel currently can only do one range at a time. This comes from something I read perhaps a month ago. I wish I had the source as this might not be true or might no longer apply.
Journalling is what kills it for me. Data corruption is a PITA.
However the newer versions of hdparm (v9.25 - Maverick is at v9.27) come with a script called wiper.sh which performs a quick analysis of a drive and then trims all the empty space. Rather than lose features, I find it much easier to cron wiper.sh to run once a week (or once a day/month/whatever). SSD degradation for an OS drive doesn't happen that fast unless you're constantly tearing things up. You don't need realtime TRIMming.
There is also a GUI frontend called DiskTRIM which doesn't appear to be in the repos. Less experienced users might find this easier to use than setting up cron jobs.
There are PPAs for hdparm and disktrim and all can be run on Lucid (and further back) without need for 2.6.33+ kernels.
In general, yes, because there are a bevy of ways to obtain newer kernels. If we clarify your question to read, "Does 10.04 LTS have support out of the box for the command?" then the answer is no. However, both Maverick's and Natty's kernels (-generic, -generic-pae, -server, and -virtual flavors) have been backported to 10.04 LTS and are available from $release-updates in the Ubuntu repositories, e.g., linux-image-generic-lts-backport-maverick is Maverick's backport to Lucid.
/sbin/wiper.sh --verbose --commit /dev/sda1
wiper.sh: Linux SATA SSD TRIM utility, version 3.3, by Mark Lord.
rootdev=/dev/sda1
fsmode2: fsmode=read-write
/: fstype=ext4
freesize = 13785252 KB, reserved = 137852 KB
Preparing for online TRIM of free space on /dev/sda1 (ext4 mounted read-write at /).
This operation could silently destroy your data. Are you sure (y/N)? y
Creating temporary file (13647400 KB)..
Syncing disks..
Beginning TRIM operations..
get_trimlist=/sbin/hdparm --fibmap WIPER_TMPFILE.9689
/dev/sda:
trimming 27294800 sectors from 462 ranges
succeeded
Removing temporary file..
Syncing disks..
Done.
However if I run it again, it shows the same number of sectors/ranges need to be trimmed, and reports success again. I get exactly the same thing every time. It doesn't look like the sectors are ever deleted/freed. Reading them still shows the same data.
Looks like there is support for the TRIM functionality in the 10.10 and newer releases:
Also, the TRIM stuff happens automatically - empty blocks are automatically released when they're no longer needed (eg, you delete a file), if the disk reports that it supports TRIM. You don't have to manually issue a hdparm command for this to work.
Jeremy's answer is not entirely accurate AFAIK. I've been running the latest stable kernels on Lucid for some time now and have been following the status of TRIM quite keenly as I have an OCZ Agility as my main disk.
Here's what (I think) I know:
The kernel has TRIM support as of 2.6.33 (Maverick is 2.6.35).
EXT4 has TRIM support but only when journaling is turned off.
The way TRIM works in the kernel is very basic and quite slow. Disks following the specs can accept multiple ranges but the kernel currently can only do one range at a time. This comes from something I read perhaps a month ago. I wish I had the source as this might not be true or might no longer apply.
Journalling is what kills it for me. Data corruption is a PITA.
However the newer versions of hdparm (v9.25 - Maverick is at v9.27) come with a script called
wiper.sh
which performs a quick analysis of a drive and then trims all the empty space. Rather than lose features, I find it much easier to cronwiper.sh
to run once a week (or once a day/month/whatever). SSD degradation for an OS drive doesn't happen that fast unless you're constantly tearing things up. You don't need realtime TRIMming.There is also a GUI frontend called DiskTRIM which doesn't appear to be in the repos. Less experienced users might find this easier to use than setting up cron jobs.
There are PPAs for hdparm and disktrim and all can be run on Lucid (and further back) without need for 2.6.33+ kernels.
Linux has support for automatic TRIM with ETX4 file system since kernel 2.6.33.
The first Ubuntu release with automatic TRIM support is 10.10 (Maveric), but it has to be activated in fstab (as described here).
In general, yes, because there are a bevy of ways to obtain newer kernels. If we clarify your question to read, "Does 10.04 LTS have support out of the box for the command?" then the answer is no. However, both Maverick's and Natty's kernels (-generic, -generic-pae, -server, and -virtual flavors) have been backported to 10.04 LTS and are available from $release-updates in the Ubuntu repositories, e.g.,
linux-image-generic-lts-backport-maverick
is Maverick's backport to Lucid.I'm running 11.04 and it doesn't look like TRIM is working according out of the box.
I tested using the instructions here to create a file, delete it, and see if the sectors get zeroed out/deleted.
I tried to enable TRIM using the instructions here, but no dice
I run wiper.sh, I get
However if I run it again, it shows the same number of sectors/ranges need to be trimmed, and reports success again. I get exactly the same thing every time. It doesn't look like the sectors are ever deleted/freed. Reading them still shows the same data.
Curious if anyone else has got it to work.