Re: [gentoo-user] Software RAID-1

[Peter Humphrey]

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:
> >> I now wonder if this is a race condition between the init script running
> >> `mdadm -As` and the fact that the mdadm package installs udev rules that
> >> allow for automatic incremental assembly?
> >
> > Isn't it just that, with the kernel auto-assembly of the root partition,
> > and udev rules having assembled the rest, all the work's been done by the
> > time the mdraid init script is called? I had wondered about the time that
> > udev startup takes; assembling the raids would account for it.
>
> Yes, it's a possibility and would constitute a race condition - even
> though it might ultimately be a harmless one.

I thought a race involved the competitors setting off at more-or-less the same 
time, not one waiting until the other had finished. No matter.

> As touched upon in the preceding post, I'd really like to know why mdadm
> sees fit to return a non-zero exit code given that the arrays are actually
> assembled successfully.

I can see why a dev might think "I haven't managed to do my job" here.

> After all, even if the arrays are assembled at the point that mdadm is
> executed by the mdraid init script, partially or fully, it surely ought
> not to matter. As long as the arrays are fully assembled by the time
> mdadm exits, it should return 0 to signify success. Nothing else makes
> sense, in my opinion. It's absurd that the mdraid script is drawn into
> printing a blank error message where nothing has gone wrong.

I agree, that is absurd.

> Further, the mdadm ebuild still prints elog messages stating that mdraid
> is a requirement for the boot runlevel but, with udev rules, I don't see
> how that can be true. With udev being event-driven and calling mdadm
> upon the introduction of a new device, the array should be up and
> running as of the very moment that all the disks are seen, no matter
> whether the mdraid init script is executed or not.

We agree again. The question is what to do about it. Maybe a bug report 
against mdadm?

--->8

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

> > Do I even need sys-fs/mdadm installed? Maybe
> > I'll try removing it. I have a little rescue system in the same box, so
> > it'd be easy to put it back if necessary.
>
> Yes, you need mdadm because 1.x metadata arrays must be assembled in
> userspace.

I realised after writing that that I may well need it for maintenance. I'd do 
that from my rescue system though, which does have it installed, so I think I 
can ditch it from the main system.

-- 
Regards
Peter