[gentoo-desktop] Re: LVM and drive renumbering

[Duncan]

Lindsay Haisley posted on Sat, 11 Sep 2010 21:22:07 -0500 as excerpted:

> On Sun, 2010-09-12 at 00:52 +0000, Duncan wrote:
>> Once you've noted the order and figured out which sdX corresponds to
>> which device, make your rootfs writable as you did before, and change
>> the corresponding fstab and intermediate layer (lvm/dmraid/mdraid/etc)
>
> Here's a question about LVM.
>
> The files under /etc/lvm make specific reference to UUIDs rather than
> /dev/?d?? files (except for the .cache file, which is expendable). If
> the /dev/?d?? drive ordering changes, will the LVM system continue to
> work once other configuration data such as /etc/mdadm.conf and
> /etc/fstab are readjusted for the new /dev drive ordering?

As I've said, I don't run LVM now tho I used to...  So verify this before 
actually relying on it if it's a data-loss or production-time risk, but I 
believe it's correct.

If your LVs are all on top of mdraid, you shouldn't have to worry about it 
at all, because it'd be the mdraid layer that would be dealing with the 
hdX/sdX changes and the LVs are built on top of that.

If they're directly on the disks (either whole or disk partitions) without 
mdraid as an intervening layer... I /think/ they should still be fine, at 
least to the degree of no data loss, tho depending on config, you /might/ 
have an issue with detection, but I'm less sure of this than the status 
when layered on mdraid.

As for mdraid, its metadata is very strong, to the point all you have to 
do is point mdadm in the general direction (if that, as it scans /proc/
partitions by default, if there's no DEVICE lines in mdadm.conf), and it 
auto-scans and auto-assembles pretty much on its own.  In fact, running 
~arch with the latest kernel, etc, I've had trouble with mdadm and udev 
auto-scanning and starting arrays I didn't even want running by default, 
even with the mdraid service entirely removed from the boot sequence 
(~arch, so baselayout-2/openrc, where mdraid has its own initscript), as 
udev was still triggering it!  I had to replace the second parameter on 
all the ARRAY lines, normally the /dev/mdX entry, with <ignore>, in 
ordered to prevent the udev triggered assemble, and then I couldn't 
trigger assemble from the command line (actually my own scripts) providing 
only the md device name, as I was doing previously, due to that same 
ignore.  (To fix that, I had to provide another parameter in the script; I 
chose --super-minor, since all my mdX numbers and super-minors correspond, 
making it easiest to script.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman