Tuning Solid State Drives in Linux
Other tweaks…
The rest of these tips have been floating around on various sites for a while now. I’m including them for completeness, and because they’ve worked well for me.
4. Mount filesystems with the noatime option
Just as you added the “discard” option to your /etc/fstab file in step 2, you can also add the “noatime” option. Using “noatime” prevents Linux from updating the last-access time for files and directories. This saves a lot of writes which should extend the life of your drive, and should also add a slight performance boost.
Using the same partition from step 2, the line in your /etc/fstab file would be changed from:
/dev/sda1 / ext4 discard,defaults
to:
/dev/sda1 / ext4 noatime,discard,defaults
Test your fstab file the same way as in step 2, using the mount command with the -oremount switch.
FYI: You can use the “noatime” option with the ext2, ext3, or the ext4 filesystems.
5. Use the noop disk scheduler
Linux has several different disk schedulers, which are responsible for determining in which order read and write requests to the disk are handled. Using the noop scheduler means that Linux will simply handle requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This is good for solid-state drives because they have no moving parts, and seek times are identical for all sectors on the disk.
To see which scheduler your system is using, view the contents of /sys/block/sda/queue/scheduler:
cat /sys/block/sda/queue/scheduler
The scheduler currently in use is listed in brackets:
[noop] deadline cfq
To force your system to use the noop scheduler by default, add the following line to your /etc/rc.local file:
echo noop > /sys/block/sda/queue/scheduler
By the way, for a good description of the different schedulers available in Linux, check out this article at Linux Magazine.
6. Move Firefox cache to a tmpfs
For most of us, using Firefox is probably responsible for the largest percentage of our disk activity. To reduce the number of writes to the disk you can move your cache to a tmpfs filesystem. Your browser cache will be stored in your physical memory (RAM), bypassing the need to store it on the disk altogether. Of course, it will be wiped out when you reboot, but most people won’t really mind that.
To create a tmpfs filesystem, you’ll need to edit your /etc/fstab file again. Adding the following line will convert your system’s /tmp directory to tmpfs:
none /tmp tmpfs defaults 0 0
After a reboot, use the mount command and verify that your change worked by looking for a line like this:
none on /tmp type tmpfs (rw)
If you’ve verified that your tmpfs has been created, open Firefox and enter about:config in the location bar. Right-click and choose the option New->String. Enter “browser.cache.disk.parent_directory” for the preference name, and for the string value enter “/tmp/firefox-cache”.
Restart Firefox, and look inside the /tmp directory to make sure the browser’s cache is being written to the new location.
Conclusion
If you understand the fundamental differences between traditional hard drives and solid-state drives, it’s easy to understand why these modifcations make sense. My guess is that within a year or two, most of these manual changes will not be necessary – SSDs will become more and more mainstream, and Linux distributions will do most of the configurations for you. But for now, I hope you find this guide to be helpful.
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 [...]
[...] http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ Answered by nicedream [...]
[...] Since 'noop' is a 'FIFO' the 'SSD' device will be serviced better than with 'deadline or 'cfq'. Tuning Solid State Drives in Linux is a good guide. SSDWiki is a good knowledge base resource. BTW, I still use mechanical drives [...]
[...] prefer to save the memory). The Arch Linux Wiki has a comprehensive page on SSDs, and here’s another article that goes more in-depth in some of the things I mentioned here. Enjoyed this post? [...]