This article explains the steps for the installation of an SSD device on an existing Ubuntu desktop PC.
First of all, let's have a look at the disk read performance with the hdparm utility. The desktop PC has three disks, /dev/sda being the new SSD device (an OCZ Vertex 2 SATA II 3.5" SSD).
The three disks have the following performance:
sda: OCZ-VERTEX2 3.5 229.47 MB/sec sdb: WDC WD3000GLFS-01F8U0 122.29 MB/sec sdc: ST3200822A 59.23 MB/sec
The SSD device appears to be 2 times faster than a 10000 rpm disk.
Plan for the move
The first step is to plan for the move and define what files should be located on the SSD device.
Identify files used frequently
To benefit of the high read performance, files used frequently could be moved to the SSD device. To identify them, you can use the findcommand and the -amin option. This option will not work if the file system is mounted with noatime. The -amin option indicates a number of minutes. To find the files that were accessed during the last 24 hours, you may use the following command:
In most cases, files accessed frequently are the system files (in /bin, /etc, /lib, ..., /usr/bin, /usr/lib, /usr/share, ...) and users' files located in /home.
Identify Files that change frequently
Some people argue that files modified frequently should not be located on an SSD device (write endurance and write performance).
On a Linux system, the system files that are changed on regular basis are in general grouped together in the /var directory. Some configuration files are modified by system daemons while they are running. The list of system directories that changes can be limited to:
/etc (cups/printers.conf.0, mtab, lvm/cache, resolv.conf, ...) /var (log/*, cache/*, tmp/*, lib/*...) /boot (grub/grubenv modified after booting)
On Linux temporary files are stored in one of the following directories. Several KDE applications are saving temporary files in the .kde/tmp-host directory for each user. These temporary files could be moved to a ram file system.
/tmp /var/tmp /home/$user/.kde/tmp-$host
The final plan was to create one partition for the root file system and three LVM partitions for /usr, /var and /home directories.
Partition the drive
The drive must be partitioned with fdisk. I created one bootable partition and a second partition with what remains.
To ease future management of partitions, it is useful to use LVM and create a volume group.
The partitions are then created by using lvcreate. More space can be allocated on them by using the lvextend utility.
The LVM partitions are available through the device mapper and they can be accessed by their name:
Format the partition
Format the file system with ext4 as it integrates various improvements which are useful for the SSD storage (Extents, Delayed allocation). Other file systems will work very well too.
Move the files
To move files from one system to another place, it is safer to use the tar command instead of a simple cp. Indeed, the tar command is able to copy special files without problems while not all cp commands support the copy of special files.
If the file system to move is located on another LVM partition, it is easier and safer to use the pvmove utility to move physical extents from one physical volume to another one.
Change the mount point
Edit the /etc/fstab file and change the old mount point to the new one. The noatime mount option tells the kernel to avoid updating the file access time when it is read.
/dev/vg01/sys /usr ext4 noatime 0 2 /dev/vg02/home /home ext4 noatime 0 2 /dev/vg01/var /var ext4 noatime 0 2
Tune the IO Scheduler
For the SSD drive, it is best to disable the Linux IO scheduler. For this, we will activate the noopIO scheduler. Other disks will use the default IO scheduler or another one. Add the following lines in /etc/rc.local file:
test -f /sys/block/sda/queue/scheduler && echo noop > /sys/block/sda/queue/scheduler