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