Re: [gentoo-user] Software RAID-1

[Peter Humphrey]

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 :)

> >>> 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).

> 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?

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.

Is nobody else experiencing this behaviour?

-- 
Regards
Peter