Lab Notes

Things I want to remember how to do.

Installing Ubuntu 12.10 on an SSD, Part 3

December 9, 2012

Recently I took the plunge and put an SSD drive into my desktop. Since I needed to re-install the OS, I figured I would install the latest Ubuntu, version 12.10. I went over my trials and tribulations of getting the OS installed in part 1, and dealt with swap in part 2. Today we finish up the tweaks for the SSD.

First we add noatime and discard to the /etc/fstab options for the drive:

UUID=abc...    /     ext4    errors=remount-ro,noatime,discard 0       1

(Note I cut my UUID for brevity. Yours should be much longer.) The noatime option keeps the OS from updating the access time of a file every time it is read. This reduces the number of writes to the SSD drive. The discard option enables the TRIM command on the file system. There are some details to delve into for this depending on your particular SSD, read about it at https://wiki.archlinux.org/index.php/Solid_State_Drives. For most drives you’ll want it enabled.

Next we change the I/O scheduler to use the deadline algorithm instead of elevator algorithm. For a traditional hard disk drive, the data is read from the platter by a head. The head must be moved to the correct position to read the desired data. The disk spins, which means the head need only move in one dimension, radially. For this reason, the scheduling algorithms for hard disk drives are referred to as elevator algorithms.

The SSD does not have the same limitations as the HDD. There is no head to move into position in order to read or write the data. So it is not really important what order the I/O is scheduled. There is no reason to force some I/O operations to wait while others, requested later, are served as would happen in the elevator algorithm. So instead we use the deadline algorithm, where each operation is assigned a deadline.

Since we have a mixed environment, we cannot just set it system wide via grub kernel options. That is, we can’t just use the elevator or deadline algorithm for all disks since we have both HDDs and SSDs. In order to use the correct algorithm with the proper drive type, create a file in /etc/udev/rules.d with contents:

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

I named mine 99-scheduler.rules. The files in this directory are automatically processed by udev, the device manager for the kernel. Note that cfq, or Completely Fair Queuing, is the default. For more information, go to http://en.wikipedia.org/wiki/CFQ.

The next tweak to make is to do something about the /tmp directory. This is another change that is designed to reduce writes to the SSD (an overblown concern) but you might appreciate the effects on your system in any case. I decided to mount the /tmp directory in RAM. Add the following to /etc/fstab (or replace any existing mount for /tmp):

none /tmp tmpfs defaults 0 0

By default this uses about half the RAM for /tmp. If you want more control, you can use a line like:

tmpfs /tmp tmpfs nodev,nosuid,size=7G 0 0

Keep in mind that certain operations that write large files to /tmp might be adversely affected; for example, burning a large DVD.

Resources: