Yesterday I installed a new 750 gig drive into my laptop to replace the existing 250 gig drive that was factory fitted. I was finding it increasingly difficult to fit the Android source code; various other git repos and most annoyingly Maven repository caches that Eclipse and friends insist on gathering in each workspace.
The transfer of the data went pretty painlessly. Mostly thanks to the flexibility of Linux for booting and good old Knoppix to allow me to easily boot from the new drive and reinstall the boot sector.
Drive Caddy Woes
I have a small drive caddy that takes 2.5 inch drives and allows them to be used as external drives. My original intention was to install the new drive in that and then use Knoppix booted from DVD to copy the contents of my existing drive to the new drive.
Within a few seconds I realised that the caddy used an IDE based drive connnector so it wouldn’t take a SATA connected drive that my laptop needs. After a few minutes searching I realised that I would have to use a desktop PC and connect both drives to that. Of course the PC only had 2 SATA connections so that meant that I didn’t have a spare connection to attach the DVD drive to boot from.
Live Data Migration
No problem! Just boot from the old drive and perform a “live” data migration to the new drive.
Running in single user mode all of the non-root partitions were unmounted to minimise the risk of filesystem corruption. The root drive had to stay mounted. In theory it would have been possible to mount it readonly but I just left it mounted read-write and made sure that it was fsck’d (filesystem consistency checked) after the migration.
Partition Table
First step in transferring the data is to ensure that the new drive has a partition table that matches that of the old drive.
Previous drive migrations have been easy but the new drive has a physical sector size of 4096 bytes whereas the previous drive used 512 bytes. This means that the exact location of each sector needs to be aligned and tweaked. The important thing is that each partition needs to at least as big as the original partition on the old drive. The additional disk space left over was added as a large LVM partion.
The other important thing is that the number of each partition is maintained. In theory this is not essential but it does make life easier.
The new partition table is as follows
richard@laptop:~$ sudo fdisk /dev/sda
The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Command (m for help): p
Disk /dev/sda: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000009ec
Device Boot Start End Blocks Id System
/dev/sda1 2048 229375 113664 de Dell Utility
/dev/sda2 229376 6526855 3148740 b W95 FAT32
/dev/sda3 6526856 48488635 20980890 83 Linux
/dev/sda4 48490496 1465149167 708329336 5 Extended
/dev/sda5 48492544 476512275 214009866 8e Linux LVM
/dev/sda6 476516352 488404991 5944320 82 Linux swap / Solaris
/dev/sda7 488407040 1465149167 488371064 8e Linux LVM
Transferring Data
With the partitions correctly configured the data from each partition needs transferring over to the new drive. The dd command does this with ease but do remember to specify a large block size to make transfer more efficient. I also stopped my LVM volumes using vgchange to minimise chances of corruption in those volumes.
vgchange -an
dd if=/dev/sda1 of=/dev/sdb1 bs=64M
dd if=/dev/sda2 of=/dev/sdb2 bs=64M
dd if=/dev/sda3 of=/dev/sdb3 bs=64M
dd if=/dev/sda5 of=/dev/sdb5 bs=64M
dd if=/dev/sda6 of=/dev/sdb6 bs=64M
Without bs specified the transfer is inefficient. Indeed with the default blocksize writes become very inefficient because the target drive has to read the data before writing because only small fragments of a sector are written at once. You can see this in the output of the iostat 5 sda command.
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 5386.80 21376.00 21038.40 106880 105192
the kB_read and kB_wrtn values are approximately equal using the default blocksize in dd. But when using a larger blocksize reads do not occur.
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 191.00 0.00 96980.00 0 484900
After copying (which may take a number of hours) then it is advisable to consistency check each partition. In my case I just checked the root partition that was copied whilst mounted read-write using
fsck -f -y /dev/sda3
Making it all bootable
After transferring the data the boot sector needs writing to the new drive. To do this the transfer PC was power down and the new drive installed into the laptop.
The laptop was now booted from a Knoppix DVD using the grub option which causes it to find a bootable partition on the disc and to use that as the root partition. Once booted the boot sector can be installed using grub-install
grub-install /dev/sda
At this stage you should be able to reboot the laptop from the new drive.
Using the additional space
Finally the new space can be added to the LVM pool using
pvcreate /dev/sda7
pvextend mygroup /dev/sda7
where mygroup is the name of the LVM volume group.
At this point the additional space can be added to a volume group using the usual LVM commands.