1 |
Lindsay Haisley posted on Sat, 11 Sep 2010 21:22:07 -0500 as excerpted: |
2 |
|
3 |
> On Sun, 2010-09-12 at 00:52 +0000, Duncan wrote: |
4 |
>> Once you've noted the order and figured out which sdX corresponds to |
5 |
>> which device, make your rootfs writable as you did before, and change |
6 |
>> the corresponding fstab and intermediate layer (lvm/dmraid/mdraid/etc) |
7 |
> |
8 |
> Here's a question about LVM. |
9 |
> |
10 |
> The files under /etc/lvm make specific reference to UUIDs rather than |
11 |
> /dev/?d?? files (except for the .cache file, which is expendable). If |
12 |
> the /dev/?d?? drive ordering changes, will the LVM system continue to |
13 |
> work once other configuration data such as /etc/mdadm.conf and |
14 |
> /etc/fstab are readjusted for the new /dev drive ordering? |
15 |
|
16 |
As I've said, I don't run LVM now tho I used to... So verify this before |
17 |
actually relying on it if it's a data-loss or production-time risk, but I |
18 |
believe it's correct. |
19 |
|
20 |
If your LVs are all on top of mdraid, you shouldn't have to worry about it |
21 |
at all, because it'd be the mdraid layer that would be dealing with the |
22 |
hdX/sdX changes and the LVs are built on top of that. |
23 |
|
24 |
If they're directly on the disks (either whole or disk partitions) without |
25 |
mdraid as an intervening layer... I /think/ they should still be fine, at |
26 |
least to the degree of no data loss, tho depending on config, you /might/ |
27 |
have an issue with detection, but I'm less sure of this than the status |
28 |
when layered on mdraid. |
29 |
|
30 |
As for mdraid, its metadata is very strong, to the point all you have to |
31 |
do is point mdadm in the general direction (if that, as it scans /proc/ |
32 |
partitions by default, if there's no DEVICE lines in mdadm.conf), and it |
33 |
auto-scans and auto-assembles pretty much on its own. In fact, running |
34 |
~arch with the latest kernel, etc, I've had trouble with mdadm and udev |
35 |
auto-scanning and starting arrays I didn't even want running by default, |
36 |
even with the mdraid service entirely removed from the boot sequence |
37 |
(~arch, so baselayout-2/openrc, where mdraid has its own initscript), as |
38 |
udev was still triggering it! I had to replace the second parameter on |
39 |
all the ARRAY lines, normally the /dev/mdX entry, with <ignore>, in |
40 |
ordered to prevent the udev triggered assemble, and then I couldn't |
41 |
trigger assemble from the command line (actually my own scripts) providing |
42 |
only the md device name, as I was doing previously, due to that same |
43 |
ignore. (To fix that, I had to provide another parameter in the script; I |
44 |
chose --super-minor, since all my mdX numbers and super-minors correspond, |
45 |
making it easiest to script.) |
46 |
|
47 |
-- |
48 |
Duncan - List replies preferred. No HTML msgs. |
49 |
"Every nonfree program has a lord, a master -- |
50 |
and if you use the program, he is your master." Richard Stallman |