Using a Solid State Drive (SSD) with Ubuntu 11.04

I have been using a Solid State Drive (SDD) for some time and I have decided to share my notes on how to do it and references I have followed. The configuration I use is to have two disks attached to my platform: the first is the SSD and holds the Operating System; the second is a magnetic drive which holds my home partition.

This note applies to:

  • Ubuntu 11.04
  • ext4

From research, the important aspects that need to be dealt with when using a SSD are:

  1. Enable TRIM
  2. Disable access timestamp on files
  3. Adjust disk scheduler
  4. Moving log files to RAM drive

Each of these topics are discussed separately below.

Enable TRIM

TRIM is the process under which an operating system tells a drive that a sector is no longer in use. This is not necessary for magnetic drives and, historically, operating systems did not provide this information to the drives as it increased the amount of information traversing between a host and its drives. However, this information is crucial for SSDs as it is needed to perform proper wear leveling.

Information on TRIM can be found via these links:

In Ubuntu, TRIM is enabled via the file “fstab” located in “/etc”. One needs to find the drive associated with the SSD and add the option “discard”. To edit the “fstab”:

Then add the “discard” option to the drive concerned. In my example, the root drive is the SSD. Therefore, the resulting file looks like:

After the “fstab” file is modified, one must reboot the system for the change to take effect.

After reboot, one should ascertain that TRIM was in fact enabled. To do so, a trick provided by Nicolay Doytchev is used (link above). However, it is claimed that this trick works with ext4. One might not get expected results from other disk format.

1. Become root and move to a directory managed by the SSD:

2. Create a file with random bytes in it:

3. Get and record the disk sector address for the beginning of the file:

Note the number under begin_LBA and use it for <ADDRESS> below:

4. Access file data from disk (replace /dev/sdX for the drive you are enabling in fstab):

The result of this should be random bytes and look like this:

5. Delete the file and synchronize the file system so that changes are pushed to the SSD:

6. Finally, repeat the command from step 4. Reading the same disk sector should yield an empty sector. For example:

Disable access time stamps on files and directories

Every time a file is accessed, a time stamp for last access is recorded with the file. It is believed that this information is generally unnecessary and that it is the source of a lot of wear on a SSD. Turning off access time stamps does not disable last modified time stamps, which are crucial to a lot of computer tools.

However, it is possible that some tools you are using rely on last access time stamps. Therefore, I suggest that you disable access time stamps separately than all other changes you make to your system. Turn it off and then leave your system unchanged for a while to see how it performs under this mode. In that period, try out all your tools. Tools that rely on file caching might not do as well as others.

Interesting links about last access time:

Disabling last access time is done by adding the options “noatime” and “nodiratime” for the SSD to the file “fstab” under the directory “/etc”. First, edit the “fstab” file:

Then, locate your drive and add the options “noatime” and “nodiratime” at the appropriate line. For example, my file looks like:

After the file is saved, one must reboot the operating system for the changes to take effect.

After reboot, you can verify that the recording of access time is not longer in effect with the following tests:

1. Move to a directory managed by the SSD and writable to your user. If your home directory is on the SSD, then the following would work:

2. Create a file for testing purposes:

3. Record the last access time:

4. Wait for a minute or two to elapse (you can use ‘date’) and then read the file:

5. Repeat command from step 3 and compare the results. If the same time is returned, then “noatime” is in effect. If a newer time is returned the second time, then the operating system is still recording access time for the file.

6. Clean up after yourself and delete the test file:

Adjust Disk Scheduler

By default, the CFQ scheduler is used to access a drive. This scheduler is designed for magnetic drives and take into account variables such as seek times. In SSDs, access time is fairly constant. Therefore, there is no need for a complex scheduler and addressing requests on a first-come-first-served basis is adequate. I have used the “noop” scheduler and this is what I demonstrate. However, there is an interesting post at this blog that might convince otherwise.

The trick offered here changes the scheduler after the boot is performed and as the operating system is starting it services. Therefore, the boot process does not benefit of these changes. The post above provides links to enable scheduler at the boot loader.

Myself, I like keeping my boot loader as clean as possible, so I have adopted this trick.

1. Edit the file “/etc/rc.local”:

2. Add the following line by taking care to replace sdX for the proper drive:

This change will take effect at the next reboot. However, to save a reboot, one can apply the change right away with (again, replacing sdX for proper drive):

Moving log files to RAM

Log files are a source of constant writing to disk. Personally, I have not yet made the change to my drive for two reasons:

  1. I am ambivalent about throwing away the logs since I sometimes rely on them to find causes of crashes. Given I keep up with the latest version of Ubuntu and that I have a set of problematic video drivers, I feel I must keep my logs around.
  2. Of all the solutions offered, I have not been able to make one work to my liking. I find a lot of solutions presented on the web are finicky and prone to errors.

However, my research indicates that this will yield to an earlier retirement of my drive. Therefore, I offer here a link that I found useful on this topic:

Other readings

Here are a couple of interesting links that might guide you in your decisions. I do not personally endorse the views presented there. However, I believe they provide good food for thoughts:


With a SSD drive, the time to boot up has greatly decreased and performance associated with my development tools as increased. Surprisingly, the general temperature reported by my laptop sensors has also gone down. However, as most activities performed on computers are “web based”, the network-bound activities have remained pretty much the same.

All in all, I have been quite satisfied with my purchase of a SSD drive.

3 Replies to “Using a Solid State Drive (SSD) with Ubuntu 11.04”

  1. very clear and no problems following your advice other than changing to noop sceduler. I don’t have a /etc/rc.local in fedora 17. I did issue sudo echo noop > /sys/block/sda/queue/scheduler but will be in effect after boot.

  2. Hi created on in /etc/rc.d/rc.local, bash script and made it executable. I seemed to run ok
    systemctl status rc-local.service
    rc-local.service – /etc/rc.d/rc.local Compatibility
    Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
    Active: active (exited) since Sat, 02 Jun 2012 00:55:45 +0100; 11s ago
    Process: 7682 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)
    CGroup: name=systemd:/system/rc-local.service

    Would there be a check if its ok next time it boots.


Leave a Reply

Your email address will not be published. Required fields are marked *