Category: Ubuntu

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
• ATA INTEL SSDSA2M080G2GC
• 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:

• Wikipedia
• Enable TRIM in Ubuntu
• Checking if TRIM is working

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:

• Ubuntu – Optimizing the OS for SSDs
• Does noatime imply nodiratime?

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:

• Ubuntu – Optimizing the OS for SSDs

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:

• SSD Myths Endurance
• More Tips

Conclusion

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.

Reference:

• Ubuntu 11.04
• iPhone 3GS with iOS 4.3

The following steps can be used to enable tethering between a platform running Ubuntu 11.04 and an iPhone. At a high level:

1. Enable tethering on iPhone
2. Install repository from Paul McEnery
3. Install necessary packages
4. Connect

Enable Tethering on iPhone

The use of iPhone tethering might be governed by your wireless plan. If data tethering is allowed, one should be able to turn it on using the “Settings” application.
In the “Settings” application, choose “Personal Hotspot” from the menu, and enable it by pushing the switch to “on”.

If one can not accomplish this step, the remainder steps from this article will be in vain.

Install repository from Paul McEnery

Adding package “python-software-properties” provides the command “add-apt-repository”. This command is then used to make it really easy to add a repository from PPA.

Install necessary packages

Once the repository is installed, installing the packages is straight forward:

During the configuration of those packages, a kernel module must be built. In the case that the kernel headers are not installed, the following error message is printed on the screen:

Module build for the currently running kernel was skipped since the kernel source for this kernel does not seem to be installed.

In this case, the proper headers must be installed. To find out which headers are required:

Then, install the headers using the following command. Ensure that you replace the proper version according to what was returned previously.

When this command completes, the iPhone module should be built. If not, then the system can be prompted to rebuild the kernel module:

Connect

Connect the iPhone to the platform using a USB cable. When the USB device is detected, an Ethernet should be established automatically.