Tuning Solid State Drives in Linux
2. Enabling TRIM Support
TRIM is a way of allowing the operating system to tell a solid-state drive when blocks are no longer needed and can be overwritten. Without TRIM, solid-state drives will eventually experience a large slowdown in write speeds, which is known as write amplification. Without getting into the gory details, the root cause is the fact that sold state drives delete data in much larger blocks than they write. When deleting data without TRIM, the drive firmware must copy an entire block into cache, delete the whole block, and then write back the contents from cache minus the deleted data – even if all data in the block has been flagged as deleted by the filesystem. With TRIM, the operating system can talk to the drive so that blocks can be marked as free at the time they are deleted from the filesystem. Solid-state drives are beginning to be released with TRIM support in their firmware, and TRIM support was added to the Linux kernel beginning in version 2.6.33.
First make sure you’re running a kernel that has TRIM support. Run the command:
uname -a
Look for the kernel version number, and if it is 2.6.33 or higher then your kernel will support TRIM. I believe that some distributions *may* be backporting the TRIM code into earlier kernel releases, but I haven’t done any reasearch into that.
Next, check to see if your drive supports TRIM using the hdparm command. Assuming your solid-state disk is /dev/sda, issue this command:
hdparm -I /dev/sda
This will output a list of drive features, with an asterisk to indicate if that feature is supported on the drive. If your drive supports TRIM, you will see a line like this:
* Data Set Management TRIM supported
(Be sure there is an asterisk at the beginning of the line – that’s what indicates if your drive supports the listed feature!)
Assuming that both your kernel and your hard drive have TRIM support, and you are using the ext4 filesystem as described above, you can now tell Linux that you want to enable it by adding the “discard” option in your /etc/fstab file. Look for the line with your ext4 filesystem, and change it from something like this:
/dev/sda1 / ext4 defaults
…to something like this:
/dev/sda1 / ext4 discard,defaults
Of course, your partition, mount point, and existing options will probably be slightly different than what’s listed above. The point is to add the “discard” option in the fourth column.
To test your newly modified fstab file, run the following (as root):
mount -oremount /dev/sda1
Then, run the command:
mount
…which will show you all mounted filesystems along with their options. Using the example above, look for the “discard” option to know you’re in business:
/dev/sda1 on / type ext4 (rw,discard)
3. What to do about swap…
Swap space is a tricky issue when it comes to solid-state drives. The need for swap has decreased considerably as the average system has several gigabytes of memory. For instance, I have 2 GB of memory and can run several virtual machines in addition to my regular web browsing and ssh sessions without maxing it out. But if you put your computer into hibernate mode, you should have swap space at least equal to the amount of memory in your system. The reason is that the contents of memory are written to swap during hibernation.
Assuming you do have swap space, I recommend changing your system’s “swappiness” parameter. Swappiness is a number from 0 to 100 that represents how aggressively Linux will move items in memory into swap space on the disk. The higher the number, the more likely the system is to move things out of memory and into swap.
To see the current swappiness setting, just view the contents of the file /proc/sys/vm/swappiness:
cat /proc/sys/vm/swappiness
When using a solid-state disk, I set my swappiness all the way down to 1. This allows me to have swap space, but ensures that it will never be used except under the most demanding circumstances. Again, this should extend the life of the disk by reducing the amount of writes. To change the swappiness value, add the following line to /etc/rc.local:
echo 1 > /proc/sys/vm/swappiness
/etc/rc.local is a file that is executed at system startup after all other init scripts have run, and is used for administrator customizations that do not fit into any of the other init scripts.
your article didnt mention how to align the drive
[Reply]
admin Reply:
April 3rd, 2010 at 4:22 pm
I know – sorry about that. When I was doing research on SSDs, aligning the drive partitions is one thing I missed.
I hope to have a section about partition alignment posted here soon.
[Reply]
[...] The SSDs-with-Linux thread. Pasting this link for reference: Tuning Solid State Drives in Linux | cptl.org Using the following since apparently Lucid has "discard" option backported now for TRIM [...]
Very helpful, and will tip me into the direction of buying a SSD. What about aligning? Did you do that?
[Reply]
[...] are so new and there isn't much long term evidence of what is truly the best way to go. FWIW, I wrote up a guide of everything I did to tune my SSD, in case anyone is interested in what I [...]
What about the discard mount time option ?
I read that TRIM is deactivated by default on ext4 and that you need to pass the discard option to mount (or in fstab) ?
[Reply]
admin Reply:
April 16th, 2010 at 8:18 am
Yes, this is explained in the article. Maybe you missed pages 2 & 3? Look between the article and the comments section.
[Reply]
Nice article, but as said earlier no mention of alignment of partitions with SSD erase block boundaries.
here is Ted Tso’s (kernel maintainer of ext4 fs) take on this matter:
http://es.linuxfoundation.org/news-media/blogs/browse/2009/02/aligning-filesystems-ssd%E2%80%99s-erase-block-size
(his original blog seems to be down right now)
[Reply]
[...] slack66 thanks for replying! sorry can you teach me step command how to enable trim in fstab? http://cptl.org/wp/index.php/2010/03…ives-in-linux/ It's on page [...]
Having an align article would make this a really useful blog for all Linux + SSD users.
I know I will use it right off.
Great work so far.
[Reply]
[...] Gex: you might find the following useful: Tuning Solid State Drives in Linux | cptl.org Reply With [...]
re: Firefox cache. No need to tmpfs it.
about:config…
browser.cache.disk.enable false
browser.cache.disk.capacity 0
browser.cache.offline.enable false
browser.cache.offline.enable 0
browser.cache.memory.enable true (default)
about:cache to verify that nothing is being written to disk (memory only).
These are the settings I use and they are working just fine.
[Reply]
admin Reply:
February 11th, 2011 at 9:11 am
True. The difference is that your setup is not storing any cache. Using tempfs allows you to use cache, but it is not saved during a reboot (since it is stored in volatile memory).
[Reply]
I just followed your guide.
For changing the default scheduler to noop, I suggest to put the elevator parameter to the kernel at boot time (in grub), instead of editing rc.local (that can be overwrited during system update).
http://www.wlug.org.nz/LinuxIoScheduler
great guide anyway. thx
[Reply]
admin Reply:
August 5th, 2010 at 10:17 am
You’re right, it can be done in the bootloader. I like to put it in my rc.local, because I use rc.local for any bootup commands added by me. I also have my firewall script, my hdparm commands, etc in there. I like to have them all in one place.
FYI, if you are compiling your own kernel you can also set the default scheduler in the kernel .config file.
[Reply]
nodiratime is another option to add to reduce unnecessary writes.
[Reply]
admin Reply:
September 10th, 2010 at 8:28 am
noatime means that last accessed timestamps are not written, ever.
nodiratime means that last accessed timestamps are not written on directories, but are still written to files.
If you specify noatime, that includes files and directories too. There is no reason to specify nodiratime if you have already specified noatime.
http://lwn.net/Articles/245002/
[Reply]
[...] See here. [...]
This is great info. Thanks a lot!
[Reply]
Re: Using NOOP on an SSD.
I would worry that the lack of write ordering in NOOP would mean *more* writes to the SSD, since only adjacent requests would be merged. The other schedulers would re-order all the outstanding writes and merge all the adjacent requests.
[Reply]
admin Reply:
February 11th, 2011 at 9:09 am
I’m not sure what you mean by this. NOOP is just a first-in first-out disk queue, so it doesn’t try to reorder the disk writes based on the sector of the disk that is to be written to. I don’t think any of the schedulers will increase or decrease physical writes, it’s only the ordering of the writes that is affected.
[Reply]
Corley Reply:
March 15th, 2011 at 3:40 pm
Ian! D. Allen seems to be under the impression that gathering write operations will help decide where they are allocated to the drive.
The destination of gathered write operations is predetermined, the gathering allows them to be re-ordered to reduce the required seek times onto a spinning disk. The actual outcome of addresses filled will be the same for any block device.
[Reply]
Some guy Reply:
April 18th, 2011 at 12:10 am
The addresses filled will be the same, but with another scheduler there will be fewer write operations. Gathering several writes to the same erase-block can be a big help for drive life (otherwise, the SSD controller may read the block, modify a small part, rewrite it, and repeat for each small write)
What about AHCI in BIOS? Will trimming work in SATA mode too?
[Reply]
question is, does this also work with encrypted partitions?
[Reply]
[...] http://cptl.org/wp/index.php/2010/03…ives-in-linux/ [...]
[...] wpis to w dużej mierze tłumaczenie tego artykułu: Tuning Solid State Drives in Linux, jednak pozwoliłem sobie dodać kilka dodatkowych informacji i wniosków do jakich doszedłem [...]
[...] This article was loaded with useful info http://cptl.org/wp/index.php/2010/03…ives-in-linux/ [...]
When I goto edit the fstab I use gksu edit /etc/fstab
Looking for /dev/sda1 / ext4 defaults I don’t see that.. I see the word ext4 but non that you refer too..also I see some that says errors-forgot-ro.
Any help?
[Reply]
admin Reply:
February 11th, 2011 at 9:05 am
/dev/sda1 is just an example. Your system may be partitioned differently, so you will need to know which partition(s) on your SSD you want to enable trim on.
I would recommend reading up on the format of the fstab file. If you aren’t sure about what you’re doing, you could easily make your system unbootable.
[Reply]
[...] [...]
[...] countless sites that describe how to enable TRIM, but I found one especially helpful. This site was cptl.org. Much of this post was based upon information on those pages but specifically directed at the XBMC [...]
On my intel ssd, using slackware 13.37 it seems that trim is not working when disabling journaling on the ext4 partition.
I checked that with hdparm. Can anyone confirm that disabling journaling affects trim support?
Because with my ssd trim worked with journaling, and without it didn’t.
[Reply]
zojxX9 http://gdjI3b7VaWpU1m0dGpvjRrcu9Fk.com
[Reply]
[...] Tuning Solid State drives in Linux [...]
[...] [1] http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ [...]
May be useful for some people: ext4 without journal requires Kernel version 2.6.29
[Reply]
Thanks for sharing this valuable information!
[Reply]
[...] discard (trim) support 和 Tuning Solid State Drives in Linux [...]
[...] stopping the EXT4 file system journaling, which speeds up the system and saves writes to the disk. This blog gives the details on the first page, and the other pages cover the stuff in the HowToGeeks [...]
[...] Welcome to LQ! Look at http://cptl.org/wp/index.php/2010/03…ives-in-linux/ Plus do not forget that 'TRIM' is now supported in new [...]
[...] http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ [...]
awesome article, really well explained.
[Reply]
[...] response Hi, Old reference that is still useful to take notice: http://cptl.org/wp/index.php/2010/03…ives-in-linux/ I like the Patriot forum & Intel Support Community. Onebuck SSD participation threads that [...]