How do I optimize the OS for SSDs?

Solution 1:

I have successfully used several different techniques to improve the way Ubuntu uses the storage device, whether that be solid state or traditional drive.

For SSD's you are looking to minimise the number of times the drive is written too, as reads should not add wear to the drive.

1) Manage the swap file

If you do not hibernate your computer and you have ample RAM memory to run all your applications, then in theory you do not need a swap partition.

If you have a mix of SSD and hard drives, place your swap partition on the hard drives only.

2) No Writes for Read Timestamps (suitable for SSD's and hard drives)

Mounting your partitions with the options noatime and nodiratime will stop timestamp writes when you read files and folders. These timestamp writes are not generally required unless you use a local mail server client such as mutt. The reason this is generally a bad idea, is because every read will produce a write when updating the timestamps. This decreases the life of the SSD.

Edit your /etc/fstab configuration file (carefully - take a backup to be sure as breaking your fstab configuration can prevent you system from working):

cp /etc/fstab ~/fstab-backup
gksudo gedit /etc/fstab

Edit the mounting options for your partitions by adding the text noatime and nodiratime to the lines defining your root (/) and other partitions if you have them (/home) - Note: if you have a /home partition, start with that just changing that partition if you are concerned about breaking something

# / was on /dev/sda2 during installation
UUID=587e0dc5-2db1-4cd9-9792-a5459a7bcfd2 /               ext4    noatime,nodiratime,errors=remount-ro 0       1

# /home was on /dev/sda3 during installation
UUID=2c919dc4-24de-474f-8da0-14c7e1240ab8 /home           ext4    noatime,nodiratime,defaults        0       2

You will need to reboot your machine before these changes take effect

3) Minimising writes from the OS and applications

Assuming that you are not running a mission critical product server, most people do not look at logs should something go wrong (especially as serious errors are rare for most Ubuntu users). Therefore you can configure Ubuntu so all logs get written to RAM memory rather than the SSD.

Note: only make the following changes when you have installed all software you are going to use (especially things like Apache web server), otherwise you may experience some issues with missing directories in /var/log

For background to this approach, see prolonging the life of your flash drive on ubuntu-eee.com

Open /etc/fstab with an editor (assuming you have backed up the /etc/fstab file)

gksudo gedit /etc/fstab

Add the following lines at the end of the fstab file and save:

# Uncomment these after all server based applications installed - eg. apache
#tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
#tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
#tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0 
#tmpfs /var/log/apt tmpfs defaults,noatime 0 0
# none /var/cache unionfs dirs=/tmp:/var/cache=ro 0 0

You will need to reboot your machine before these changes take effect

See also:

• How to enable TRIM?

Solution 2:

SSD Life

Generally I wouldn't bother - the worries about SSD life are overblown. You can read this detailed article about why you really shouldn't worry. In short the circuitry inside modern SSDs manages wear-levelling for you, and they know how to do it far better than you.

In the article is a calculation of the life of an SSD that is receiving writes at a continuous rate of 80M/s. The life is 51 years. That is based on 2007 technology - SSD life will be longer now. And you almost certainly don't write to your SSD at 80M/s 24 hours a day.

SSD Performance

However performance degradation over time can be a problem, and TRIM is the solution. There are two options

• automatic/online TRIM, aka discard
• manual TRIM

You have to enable automatic TRIM yourself . (Basically you add the discard option to your mount options, provided you are using ext4.) I have found a blog post reporting that the discard option slows down your system when deleting files.

You can occasionally do it manually (or in a cron job) using fstrim. If you just have one partition then all you need to do is:

sudo fstrim /

Note that fstrim is only available in 11.10 and newer. For older systems you will need the wiper.sh script. I found the script at /usr/share/doc/hdparm/contrib/wiper.sh.gz on my system.

If you're wondering, the problem that TRIM solves, as described by Wikipedia, is:

SSDs store data in flash memory cells that are grouped into pages, with the pages (typically 4 kB each) grouped together into blocks (typically 128 pages per block, totaling 512 kB). NAND flash memory cells can only be directly written to when they are empty. If they are considered to contain data, the contents first need to be erased before a write operation can be performed reliably. In SSDs, a write operation can be done on the page-level, but due to hardware limitations, erase commands always affect entire blocks. As a result, writing data to SSD media is very fast as long as empty pages can be used, but slows down considerably once previously written pages need to be overwritten. Since an erase of the cells in the page is needed before it can be written again, but only entire blocks can be erased, an overwrite will initiate a read-erase-modify-write cycle: the contents of the entire block have to be stored in cache before it is effectively erased on the flash medium, then the overwritten page is modified in the cache so the cached block is up to date, and only then is the entire block (with updated page) written to the flash medium. This phenomenon is known as write amplification.