1 |
On 26/08/2014 15:54, Peter Humphrey wrote: |
2 |
> On Tuesday 26 August 2014 14:21:19 Kerin Millar wrote: |
3 |
>> On 26/08/2014 10:38, Peter Humphrey wrote: |
4 |
>>> On Monday 25 August 2014 18:46:23 Kerin Millar wrote: |
5 |
>>>> On 25/08/2014 17:51, Peter Humphrey wrote: |
6 |
>>>>> On Monday 25 August 2014 13:35:11 Kerin Millar wrote: |
7 |
> --->8 |
8 |
>> Again, can you find out what the exit status is under the circumstances that |
9 |
>> mdadm produces a blank error? I am hoping it is something other than 1. |
10 |
> |
11 |
> I've remerged mdadm to run this test. I'll report the result in a moment. |
12 |
> [...] In fact it returned status 1. Sorry to disappoint :) |
13 |
|
14 |
Thanks for testing. Can you tell me exactly what /etc/mdadm.conf |
15 |
contained at the time? |
16 |
|
17 |
> |
18 |
>>>>> Here's the position: |
19 |
>>>>> 1. I've left /etc/init.d/mdraid out of all run levels. I have nothing |
20 |
>>>>> but comments in mdadm.conf, but then it's not likely to be read anyway |
21 |
>>>>> if the init script isn't running. |
22 |
>>>>> 2. I have empty /etc/udev rules files as above. |
23 |
>>>>> 3. I have kernel auto-assembly of raid enabled. |
24 |
>>>>> 4. I don't use an init ram disk. |
25 |
>>>>> 5. The root partition is on /dev/md5 (0.99 metadata) |
26 |
>>>>> 6. All other partitions except /boot are under /dev/vg7 which is built |
27 |
>>>>> on top of /dev/md7 (1.x metadata). |
28 |
>>>>> 7. The system boots normally. |
29 |
>>>> |
30 |
>>>> I must confess that this boggles my mind. Under these circumstances, I |
31 |
>>>> cannot fathom how - or when - the 1.x arrays are being assembled. |
32 |
>>>> Something has to be executing mdadm at some point. |
33 |
>>> |
34 |
>>> I think it's udev. I had a look at the rules, but I no grok. I do see |
35 |
>>> references to mdadm though. |
36 |
>> So would I, only you said in step 2 that you have "empty" rules, which I |
37 |
>> take to mean that you had overridden the mdadm-provided udev rules with |
38 |
>> empty files. |
39 |
> |
40 |
> Correct; that's what I did, but since removing mdadm I've also removed the |
41 |
> corresponding, empty /etc/udev files. |
42 |
> |
43 |
> I don't think it's udev any more; I now think the kernel is cleverer than we |
44 |
> gave it credit for (see below and attached dmesg). |
45 |
|
46 |
Absolutely not ... |
47 |
|
48 |
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#A_Note_about_kernel_autodetection_of_different_superblock_formats |
49 |
|
50 |
https://github.com/torvalds/linux/blob/master/Documentation/md.txt |
51 |
|
52 |
Both texts state unequivocally that kernel autodetection/assembly only |
53 |
works with the old superblock format. |
54 |
|
55 |
Having read your dmesg.txt, I can only conclude that all of the arrays |
56 |
that the kernel is assembling are using the old superblock format, |
57 |
contrary to the information you have provided up until now. If so, then |
58 |
you do not rely on any of the three methods that I (correctly) said were |
59 |
necessary for 1.x superblock arrays. |
60 |
|
61 |
To settle the matter, check the superblock versions using the method |
62 |
described below. |
63 |
|
64 |
> |
65 |
>> If all of the conditions you describe were true, you would have eliminated |
66 |
>> all three of the aformentioned contexts in which mdadm can be invoked. Given |
67 |
>> that mdadm is needed to assemble your 1.x arrays (see below), I would expect |
68 |
>> such conditions to result in mount errors on account of the missing arrays. |
69 |
> --->8 |
70 |
>> Again, 1.x arrays must be assembled in userspace. The kernel cannot |
71 |
>> assemble them by itself as it can with 0.9x arrays. If you uninstall |
72 |
>> mdadm, you will be removing the very userspace tool that is employed for |
73 |
>> assembly. Neither udev nor mdraid will be able to execute it, which |
74 |
>> cannot end well. |
75 |
> |
76 |
> I had done that, with no ill effect. I've just booted the box with no mdadm |
77 |
> present. It seems the kernel can after all assemble the arrays (see attached |
78 |
> dmesg.txt, edited). Or maybe I was wrong about the metadata and they're all |
79 |
> 0.99. In course of checking this I tried a couple of things: |
80 |
> |
81 |
> # lvm pvck /dev/md7 |
82 |
> Found label on /dev/md7, sector 1, type=LVM2 001 |
83 |
> Found text metadata area: offset=4096, size=1044480 |
84 |
> # lvm vgdisplay |
85 |
> --- Volume group --- |
86 |
> VG Name vg7 |
87 |
> System ID |
88 |
> Format lvm2 |
89 |
> Metadata Areas 1 |
90 |
> Metadata Sequence No 14 |
91 |
> VG Access read/write |
92 |
> VG Status resizable |
93 |
> MAX LV 0 |
94 |
> Cur LV 13 |
95 |
> Open LV 13 |
96 |
> Max PV 0 |
97 |
> Cur PV 1 |
98 |
> Act PV 1 |
99 |
> VG Size 500.00 GiB |
100 |
> PE Size 4.00 MiB |
101 |
> Total PE 127999 |
102 |
> Alloc PE / Size 108800 / 425.00 GiB |
103 |
> Free PE / Size 19199 / 75.00 GiB |
104 |
> VG UUID ll8OHc-if2H-DVTf-AxrQ-5EW0-FOLM-Z73y0z |
105 |
> |
106 |
> Can you tell from that which metadata version I used when I created vg7? It |
107 |
> looks like 1.x to me, since man lvm refers to formats (=metadata types) lvm1 |
108 |
> and lvm2 - or am I reading too much into that? |
109 |
|
110 |
LVM has nothing to do with md. I did allude to this in my first response |
111 |
on the thread. The above output demonstrates that you have designated an |
112 |
md block device as a PV (LVM physical volume). Any block device can be a |
113 |
PV - LVM does not care. |
114 |
|
115 |
When I talk about 1.x metadata, I am talking about the md superblock. |
116 |
You can find out what the metadata format is like so:- |
117 |
|
118 |
# mdadm --detail /dev/md7 | grep Version |
119 |
|
120 |
To be clear, LVM does not enter into it. |
121 |
|
122 |
> |
123 |
> See here what the postinst message said when I remerged sys-fs/mdadm-3.3.1-r2 |
124 |
> for the return-code test you asked for: |
125 |
> |
126 |
> * If you're not relying on kernel auto-detect of your RAID |
127 |
> * devices, you need to add 'mdraid' to your 'boot' runlevel: |
128 |
> * rc-update add mdraid boot |
129 |
> |
130 |
> Could be thought ambiguous. |
131 |
|
132 |
I would go so far as to say it is false, but this is a distinct matter. |
133 |
|
134 |
> |
135 |
> Is nobody else experiencing this behaviour? |
136 |
> |
137 |
|
138 |
--Kerin |