Migrating your system disk to an SSD
Replacing your hard drive with an SSD is a sure way to speed up your system; however, migrating to an SSD is a little more complicated than you might imagine. We'll help you find your way through the pitfalls.
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.
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
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.
Before you copy any data to the SSD, you have to partition it. A graphical tool like GParted  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).
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
/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.
Buy this article as PDF
Makes it easier for customers to move workloads into container-centric applications.
SUSE’s answer to container-centric operating systems.
Linux 4.9 is the biggest release in terms of number of commits.
The latest version of the official RHEL clone is here.
New release targets Linux professionals.
The Fedora project adds Wayland and Gnome 3.22
CeBIT 2017: Open Source Forum Call for Papers
Long-time Linux antagonist joins the revolution.
Major bug affects Debian/Ubuntu distributions.
Canonical releases the minimal edition for embedded devices, Internet of Things, and cloud deployments.