Planning for and Optimizing Solid State Drives

This past week, we installed our first Solid State Drive. We had a lot of concern about this technology early on. There were reports of gradual performance degradation.This has been improved, however, and we’ll discuss some ways to better optimize your experience. Hopefully, in future Linux releases some of these options will be configured automatically

The biggest development that has been made to preserve longevity on these drives is TRIM. The TRIM command allows the operating system to inform the drive which data blocks are no longer in use and can be wiped. TRIM is supported beginning in kernel 2.6.33 and can be enabled under Linux by editing the mount options to include the discard option, such as in the below example.

/dev/sda1 / ext4 discard,defaults

Other suggestions include removing journaling and limiting read and writes to the drive. This will extend life as well, but without journaling, there is some risk of data loss in the event of a crash. However, Theodore Tso debunked this thought last year in a blog post, in which he concluded that the overhead is minimal.

  • Another Linux-based tuning technique is to disable Linux from writing the last accessed time to files. This can be done by adding noatime to the above command. Realistically, on many computers the last accessed time is not extremely important. Do not confuse accessed time with the last modified time.
  • Add the option elevator=deadline to your grub boot configuration to use the deadline disk scheduler. If you have a slower CPU go for the noop scheduler. The default schedulers are optimized for traditional hard drives.
  • Move your Firefox Cache to RAM – 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 “/dev/shm/”. That will also reduce writes and improve performance.
  • Reduce kernel swappiness(the tendency for the OS to swap from physical memory to a hard drive based swap file). Add vm.swappiness  = ? to /etc/sysctl.conf. Default is 60, out of 0-100. Some suggest lowering it all the way to 0. Experiment with what works for you. This suggestion is not limited to systems with SSDs.

Bear in mind for the Firefox and Swappiness suggestions, you should have enough RAM to support reducing the swap and moving the cache to memory.

Now that we’ve covered optimizing the solid state drive, let’s discuss usage. We used the Kingston 30GB SSD, reviewed here in comparison to the Intel value SSD, which we also considered. The SSD, because of price and size considerations, is not ideal for all functions. You can see a picture of it just before install in the laptop we used to write this blog entry above.

SSDs are small in size, but speedy. Their best use is as an operating system drive. In our first test case, which is a laptop, they are the only drive. However, the laptop is mostly OS only. All media and other files are stored on a file server. With this drive, the laptop flies along and is extremely quiet as an SSD makes no noise. We have not done any battery life tests, but there is some evidence from those who have that some SSDs may be less energy efficient than conventional hard drives.

In conclusion, with the price of SSDs continuing to drop, it is a good time to start considering it as a boot/OS drive for your systems. Now that we’ve grown comfortable with its usage, we plan on expanding it to future renovations, including in our file server.

Update(06/03/10): The day after we wrote this, AnandTech released a review of three SSDs, including our Kingston 30GB as well as the Onyx and Intel budget SSDs. Certainly makes us feel better about our purchase.

1 thought on “Planning for and Optimizing Solid State Drives”

Leave a Comment