Re: Raid 10 question/problem [ot]

From: Michael Tokarev
Date: Sun Jan 28 2007 - 14:44:52 EST


Jan Engelhardt wrote:
> On Jan 28 2007 12:05, Michael Tokarev wrote:
[]
>> Mdadm creates those nodes automa[tg]ically - man mdadm, search for --auto.
>
> Note that `mdadm -As` _is_ run on FC6 boot.

See above -- man mdadm, search for --auto. -A = --assemble, -s = --scan.

>> In order for an md array to be started up on boot, it has to be specified
>> in /etc/mdadm.conf. With proper DEVICE line in there. That's all.
>
> That's how it is, and it does not work.

Sure. Because of this missing --auto flag.

> openSUSE 10.2:
> no mdadm.conf _at all_, /etc/init.d/boot.d/boot.md is chkconfig'ed _out_,
> _no_ md kernel module is loaded, and I still have all the /dev/md nodes.

And no udev. Or, alternatively, *all* md devices are created by some other
script or somesuch. There's No Magic (tm).

[]
> # mdadm -C /dev/md1 -e 1.0 -l 1 -n 2 /dev/sdb2 /dev/sdc2
> mdadm: error opening /dev/md1: No such file or directory
>
> Showstopper.

Nonsense. See above again, man mdadm, search for --auto.

[]
> You see, I have all the reason to be confused.

Yeah, this is quite... confusing.

It's all due to the way how mdadm iteracts with the kernel and how
udev works - all together. The thing is - in order to assemble an
array, proper device node has to be in place. But udev wont create
it until array is assembled. Chicken&eggs problem.

Exactly due to this, the node(s) can be created with mdadm (with --auto
option, whicih can be specified in mdadm.conf too), AND/OR with some
startup script before invoking mdadm, AND/OR when the system isn't
broken by udevd (with ol'good static /dev).

>> But in any case, this has exactly nothing to do with kernel.
>> It's 100% userspace issues, I'd say distribution-specific issues.

..And each distribution uses its own kludge/workaround/solution for
this stuff - which you demonstrated... ;)

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/