LVM and rescuing systems

Posted Jun 10, 2011 13:27 UTC (Fri) by tialaramex (subscriber, #21167)
In reply to: LVM and rescuing systems by epa
Parent article: Fedora 16 to use Btrfs as its default filesystem

Isn't the LVM approach to this "new hard disk" problem actually simpler, in the scenario you describe where both drives can be, at least temporarily, connected at once?

This is a job for 'pvmove'. By contrast to 'fdisk' and 'cp -a' it seems as though pvmove has many benefits.

It's restartable (so after that surprise Linux graphics crash, you can continue where you left off with no damage done)

It doesn't treat metadata specially, so you won't accidentally lose or corrupt anything

It's error-free. You can't accidentally forget and not copy everything, the source PV won't be empty (and thus can't be removed from the VG) until you've successfully moved everything off.

Did I miss something? Other than the fact that volume management isn't a familiar activity to ordinary users whereas file copying is?

LVM and rescuing systems

Posted Jun 10, 2011 13:58 UTC (Fri) by ricwheeler (subscriber, #4980) [Link]

If you look at the commands that btrfs uses (or ZFS for that matter), the consensus seems to be that they are much more intuitive.

No need to take away or obsolete any existing CLI or API's, but we do need to get at least the easy things done in a consistent way.

LVM and rescuing systems

Posted Jun 10, 2011 14:01 UTC (Fri) by epa (subscriber, #39769) [Link] (9 responses)

I wasn't aware of the pvmove command - but then, I suppose a true newcomer wouldn't be aware of fdisk either.

So would you power down your machine, plug in the new disk, power up, run fdisk to create boot and data partitions on the new disk, (* insert pvmove command here *), do something with GRUB, power down, unplug the old disk and it all works?

(If the two disks are the same size then I suppose you could dd the entire raw disk image, partition table and all, from one to the other. But that won't work if upgrading to a larger disk.)

LVM and rescuing systems

Posted Jun 10, 2011 14:18 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Your description sounds roughly right. I don't do a lot of disk upgrades on my home PCs, and the improving financial prospects at work have meant we can afford an actual sysadmin - so it's possible we're missing a step.

From dim memory I recall "do something with GRUB" is the trickiest bit, but the last time I did this (and thus the sharpest in my mind) it was with RAID 1 plus I was simultaneously trying to switch a Fedora system from ordinary LVM to LUKS encrypted LVM by hand, which in hindsight was not a good idea although I'm using that system to post this so it clearly worked.

LVM and rescuing systems

Posted Jun 10, 2011 21:37 UTC (Fri) by niner (subscriber, #26151) [Link] (7 responses)

Actually nowadays with SATA you don't even have to power down your machine. Just plug in that new disk, create partitions, add them as physical volumes to your volume group and do a pvmove off the old disk. When it's finished, you can remove your old disk from the volume group and just unplug the disk. During the whole thing, you can use your computer as usual doing all the important stuff like playing music to make this work nicer :)

LVM and rescuing systems

Posted Jun 13, 2011 7:22 UTC (Mon) by epa (subscriber, #39769) [Link] (6 responses)

So a typical consumer-grade motherboard lets you plug in new SATA devices to its SATA sockets while things are running? I never dared to try.

Hotplug

Posted Jun 13, 2011 16:59 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (2 responses)

The only scary bit of hotplug is the connector design, which I believe is correct for SATA as well as eSATA. The connector needs to be designed so that pins connect and disconnect in a well defined order. You can see this on a (standard) USB connector where a system ground (metal outer sheath) is connected first, then the USB power, then the shortest pins are data.

If that's done right then it rules out all the terrifying electrical mishaps that might otherwise be possible. Beyond that yes, a modern AHCI implementation should be capable of ensuring that a disk is quiescent, and cope with it subsequently vanishing, and then cope with a new device appearing and properly initialise it.

Early SATA hardware sometimes did not include the actual hotplug mechanism (ie waking up the driver and telling it a new device was added). But even then, as with IDE where hot plug wasn't intended to be possible at all, the operator could just prod the driver to take another look and see whether there isn't in fact a new device connected to a specific port. Not as user-friendly, but in the context of 'type pvmove' probably adequate.

Hotplug

Posted Jun 14, 2011 11:08 UTC (Tue) by nye (subscriber, #51576) [Link] (1 responses)

So if one were to try hotplugging a SATA drive, what would be the correct order of connecting/disconnecting the power and data cables?

Hotplug

Posted Jun 14, 2011 18:25 UTC (Tue) by bronson (subscriber, #4806) [Link]

Always ensure a good ground first. Ground is on the power cable.

Actually, for sata it shouldn't matter too much since the data cable has longer dedicated ground pins too. But, in general, power first.

LVM and rescuing systems

Posted Jun 13, 2011 23:34 UTC (Mon) by zuki (subscriber, #41808) [Link]

Yeah, it has worked fine for years. Some years ago the hotplug mechanism would work -- ie. the autodetection of new drives wouldn't work, hence the sata coldplug patches -- but nothing would break, but for a long time it has been working perfectly.

SATA and hot plugging

Posted Jun 16, 2011 10:21 UTC (Thu) by Cato (guest, #7643) [Link] (1 responses)

You do need to have AHCI enabled in the BIOS for eSATA hotplug to work - most modern motherboards support this, and Windows 7, but if you are dual booting with Windows XP you may have to revert to the non-AHCI mode.

SATA and hot plugging

Posted Jun 20, 2011 15:46 UTC (Mon) by nye (subscriber, #51576) [Link]

>You do need to have AHCI enabled in the BIOS for eSATA hotplug to work - most modern motherboards support this, and Windows 7, but if you are dual booting with Windows XP you may have to revert to the non-AHCI mode.

FWIW, if you had Windows XP pre-installed or if you managed to get the correct driver to the Windows installer[0] then you should have no problems with AHCI, but once it's installed Windows (XP at least) is very unhappy if you switch between AHCI and non-AHCI. Linux of course has handled the change transparently for years.

[0] Via learning how to make a slipstreamed install disc, or doing the "find an old floppy disk drive, install it to an existing machine, find 4 billion old floppy disks in the cellar/loft/garage, spend 6 hours finding one that still works reliably, save the driver to it, install the floppy disk drive in the new machine, install Windows and press F6 at the appropriate time" dance.