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:
- Enable TRIM
- Disable access timestamp on files
- Adjust disk scheduler
- 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:
|
# /etc/fstab: static file system information. # # Use 'blkid -o value -s UUID' to print the universally unique identifier # for a device; this may be used with UUID= as a more robust way to name # devices that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc nodev,noexec,nosuid 0 0 # / was on /dev/sdb1 during installation UUID=c72f9086-c306-42c6-956b-77bd546eff25 / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1 |
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:
|
dd if=/dev/urandom of=tempfile count=20 bs=512k oflag=direct |
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):
|
hdparm --read-sector <ADDRESS> /dev/sdX |
The result of this should be random bytes and look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
|
root:/etc# hdparm --read-sector 101193728 /dev/sdb /dev/sdb: reading sector 101193728: succeeded 036b f924 492b f3e3 2f36 d68b 2bf5 6eba a747 2855 136d b22b ffb3 7496 b412 1342 1bd1 0a1a 2427 176f 4a6c f81f a8a4 9d8b e869 1681 9a25 10f4 ecb4 fe4f 02dd 5290 23bf aec2 8b3c ae70 4f96 9cf6 dc19 ccd7 f112 8984 e01f e8fb c842 fbe9 f57b 4a95 13b7 8a7b 995a 719d 5449 8340 bbe6 5aab 0a0d 3533 fa57 2493 d746 a312 0440 eef5 04ae ff48 b57e 98c9 1a7e 5479 4f51 eaff 7ef4 5025 8242 32c4 beec 6fcd ce98 7522 16e3 d8e2 04da 0d66 bc06 fce6 c434 c376 403d cce0 afdd 4643 4781 8e71 a607 f5dc ad7c 2fb1 7f00 0aab 19f2 d99e d456 d80d 1fab 2f80 da20 6f8d aced 2ac7 97a2 437e 1240 a07b a80b 12b1 9d35 5028 bcf8 6584 386a 20e0 1955 7ec7 3ce8 7de3 07c1 04d2 fec3 e61d c842 3e6b da74 789e a5cb f7a1 e6bf aff0 9578 bfed 65a3 592a 3d82 0c80 cbcb cc62 6f4b fff5 9d92 f06c 0268 3f78 8b88 edac 9af8 cfba 919c 72c7 8bc6 b25f 195e a4f5 8ba9 ef44 973d 7775 6b19 7566 8885 8003 5338 6ff0 3642 e4c5 a04d a305 f227 475f ddfe ac52 be67 94cd ffea 83f0 f055 4862 7b6b 7219 7df0 a990 98ec c3fd fc84 de89 47c0 7b83 07c9 ef4d 20b5 b72d 1955 2860 c1a7 2c30 83d9 1dbe 4420 0866 b1af efa8 9a5a dd72 554e 4d8a 80d3 0288 d3b3 d7b1 75ea 9e62 7476 2581 6ec4 3c1c de08 b66a 6d1e af0d f6e9 c89b 9fb3 c072 94b6 a3b7 d586 a653 b61a c3fc 677f 4337 bfad 0bdf 8602 9ac6 5a47 e559 707e 9914 3b0f 96f8 d4a6 dc20 8d6a 32d0 516a bc5d |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
|
root@Mobile-1720:/etc# hdparm --read-sector 101193728 /dev/sdb /dev/sdb: reading sector 101193728: succeeded 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 |
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:
|
# /etc/fstab: static file system information. # # Use 'blkid -o value -s UUID' to print the universally unique identifier # for a device; this may be used with UUID= as a more robust way to name # devices that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc nodev,noexec,nosuid 0 0 # / was on /dev/sdb1 during installation UUID=c72f9086-c306-42c6-956b-77bd546eff25 / ext4 discard,noatime,nodiratime,errors=remount-ro 0 1 |
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:
|
echo noop > /sys/block/sdX/queue/scheduler |
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):
|
sudo echo noop > /sys/block/sdX/queue/scheduler |
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:
- 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.
- 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:
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.