Drive Fast

Today's consumer SSD is nearly as inexpensive as a good hard drive. The low price and high performance of an SSD makes it an attractive replacement for a conventional disk. Users can expect a five- to sevenfold speed increase, which accelerates nearly everything: the boot process, application launch, and I/O-bound operations.

But when it is time to migrate your existing system disk to an SSD, it pays to plan and proceed carefully. In this article, I show you how to avoid the pitfalls and achieve the maximum performance edge.

Drive Size

You might think you can just copy the data when you migrate from a conventional hard disk to an SSD drive, but a simple copy operation only works in the best-case scenario. You will have many possible hurdles to consider when moving to an SSD. The first question is the size of the SSD. Your SSD drive is probably a bit smaller than the hard drive, only because of cost. Migrating to a smaller storage device isn't a problem (as long as your data doesn't exceed the size of the device), but keep in mind that you can't use disk copy tools such as dd or partimage (the basis for Clonezilla) . These tools will only work if the target partition is at least as big as the source partition. You need a tool that does a logical copy file-by-file instead of sector-by-sector. Rsync is a popular option for logical copy operations.

One alternative is to shrink the source partition, but this option doesn't work for all filesystems. For instance, the fast and flexible XFS filesystem lets you increase, but not decrease, the partition size. You also can't reduce the size of a JFS or Reiser4 partition.

Boundaries

Before you copy any data to the SSD, you have to partition it. A graphical tool like GParted [1] can easily partition your SSD drive, but you need to be sure you don't overlook one important issue: partition alignment.

An SSD does not work with the 512-byte blocks used in a normal hard drive, but with 4KB blocks. If a partition does not start on a 4KB boundary, each read or write access requires twice as many operations, because each filesystem block spans two physical sectors. Starting on a 4KB boundary greatly improves read and write performance. It is especially important to be sure the first partition does not start at sector 63, where it usually starts with hard disks (Figure  1).

Figure 1: Bad partition alignment generates twice as many read and write operations.

Moving the System

If you plan to move the operating system or other important files that make reference to the original disk, you have to proceed carefully. For one thing, to boot from the new disk, you'll need a Master Boot Record (MBR), which resides outside of the partitions in the first sector of the medium. The MBR contains the partition table and a bootloader: the first link of a chain that brings the operating system into memory and starts the first process.

You could copy the MBR from the old disk using dd or some other copy command, but copying the MBR won't work. For one thing, you would overwrite your carefully aligned partition table (unless you use bs=440 to retain the original partition table and disk signature). Even if you did manage to move the MBR, though, your system wouldn't boot; configuration files like fstab or /boot/grub/grub.cfg work with partition UUIDs and won't deal with the old device names anymore. A UUID (Universal Unique Identifier) is a 16-byte expression like fc3065ec-00dc-4c80-9da2-175b94b00697. You can display these values as root user with the blkid command. Because the UUID is unique, it is bound to be different when you move from the hard drive to the SSD. You could always restore the former UUIDs using the tune2fs (ext2/3/4) or xfs_admin (XFS) command, but this option is risky and too much trouble. There is an easier way.

If you have a dual-boot system, the situation is even more complicated. Windows uses partition serial numbers instead of UUIDs. These shorter numbers must not change; otherwise, you run into problems with Windows licensing.

Time to make a battle plan.