LVM and drive renumbering
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?
Lindsay Haisley | SUPPORT NETWORK NEUTRALITY
FMP Computer Services | --------------------------
512-259-1190 | Boycott Yahoo, RoadRunner, AOL
http://www.fmp.com | and Verison
LVM and drive renumbering
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
|All times are GMT. The time now is 01:01 PM.|
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.