[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45BCFD10.4070302@tls.msk.ru>
Date: Sun, 28 Jan 2007 22:44:16 +0300
From: Michael Tokarev <mjt@....msk.ru>
To: Jan Engelhardt <jengelh@...ux01.gwdg.de>
CC: Marc Perkel <mperkel@...oo.com>, linux-kernel@...r.kernel.org
Subject: Re: Raid 10 question/problem [ot]
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists