There is sliced bread, and then there is LVM.
Today I had a pleasantly easy time migrating one of my servers from a 40Gb
disk to a 120Gb disk, thanks to LVM.
Background
A few months ago, caesar, my general purpose box, blew
up. It's motherboard was of the vintage that couldn't cope with a disk
larger than 32Gb, so it had a 40Gb hard drive in it, jumpered to look like a
32Gb disk. Apparently I could have probably fudged the geometry of a larger
disk in the BIOS so that it would boot, but I survived with a small disk,
and wasn't keen on reinstalling at the time.
When I replaced caesar, it was capable of using a larger disk, but I
just did a direct disk swap from the old caesar to the new one, and
got on with my life. I subsequently replaced daedalus, my web server
in Brisbane, which made two 120Gb disks available.
Recently, I started hitting the limits of the 32Gb disk, and the old
daedalus (recycled into minotaur) was just sitting around with
a 120Gb disk in it, not doing very much, so I decided to try and migrate
from the 40Gb disk to the 120Gb disk.
Partition layout
The way I generally partition a disk is I have a 512Mb partition for my root
filesystem, a swap partition as big as the swap allocation recipe I'm
subscribing to at the time, and use the rest as a physical volume for LVM.
Copying the root filesystem
So I took the 40Gb disk out of caesar, put it into minotaur as
the primary disk with the 120Gb disk as the slave, and booted into
single-user mode. Next, I created a partition for the root filesystem on the
120Gb disk the same size as it was on the 40Gb disk. I ensured the root
filesystem was mounted read-only, so everything would be consistent, and
used dd to copy /dev/hda1 to /dev/hdb1. Next, I shut down and
reconnected /dev/hdb (the 120Gb disk) as /dev/hda to make sure I could boot
from it okay. I think because this disk had previously had minotaur's
Linux installation on it, with GRUB, this worked fine. I'd probably have had
to dick around with installing GRUB in the MBR otherwise.
Moving the logical volumes
Once I was satisfied that I could boot from the 120Gb disk, I swapped back
again so I was booting from the 40Gb disk as /dev/hda, and again booted into
single-user mode. I did a pvcreate on /dev/hdb3, and then a
pvmove /dev/hda3 /dev/hdb3 and sat back and twiddled by thumbs for
a while.
At about 72 percent, I got a kernel oops and the pvmove bailed out. I
started to worry a bit at this point, and retried the pvmove without any
arguments. According to the manpage, it's supposed to restart from the last
checkpoint. In hindsight I should have rebooted straight away, as the kernel
obviously now had its knickers in a knot. The pvmove didn't seem to
progress, and I couldn't interrupt it, so I had to do a hard reset. As
Debian's single-user mode tends to do a hell of a lot (including mounting
all the filesystems), the mounting of one of my ReiserFS filesystems seemed
to also cause the kernel to oops also. So I rebooted with the "emergency"
argument instead, and manually ran just enough of the rcS.d scripts to get
the logical volumes available, and reran the pvmove again. This time it
completed successfully.
I then used vgremove to remove /dev/hda3, which no longer had any
extents allocated to it, from my volume group, and then did a
pvremove on it for good measure. I disconnected the 40Gb disk, and
booted with the 120Gb disk as the master, and all was good.
I put the 120Gb disk back into caesar, and if I hadn't had to pull it
out of the "rack" to stick a head on it to discover that it wanted me to
press F1 because the 40Gb disk had turned into a 120Gb disk, that part would
have been interventionless.
So I was very pleased with how easy the whole process was. If I hadn't had
those couple of kernel oopses, it would have been a piece of cake (and the
oopses didn't really give me that much grief anyway, thanks to the
checkpointing). So LVM would be great with an environment where SMART was
accurately predicting the demise of a disk. You could ideally migrate all
the data off a failing disk, probably without rebooting, and if the disks
were hot pluggable, just remove it from the system without any downtime. Of
course, it's no substitute for a good bit of RAID, but pretty cool
nonetheless.