* Linux software RAID vs. udev
@ 2004-05-01 1:25 Kevin P. Fleming
2004-05-04 2:11 ` Neil Brown
0 siblings, 1 reply; 4+ messages in thread
From: Kevin P. Fleming @ 2004-05-01 1:25 UTC (permalink / raw)
To: linux-raid
I'm switching my boxes over to udev and fully hotplug-driven /dev
directories.
However, that means by default I only have /dev/md0 from the MD driver,
and if I want to "mdadm --assemble" any other array I have to manually
create the device node for it first.
Is there any chance that mdadm is going to learn how to assemble an
array without having the device node for it already present? If so, then
the starting of the array would get the device node created (since it
would be a new block device) and everything would be happy...
(Please keep my address in the CC list, I'm not subscribed)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux software RAID vs. udev
2004-05-01 1:25 Linux software RAID vs. udev Kevin P. Fleming
@ 2004-05-04 2:11 ` Neil Brown
2004-05-04 3:06 ` Kevin P. Fleming
0 siblings, 1 reply; 4+ messages in thread
From: Neil Brown @ 2004-05-04 2:11 UTC (permalink / raw)
To: kpfleming; +Cc: linux-raid
On Friday April 30, kpfleming@backtobasicsmgmt.com wrote:
> I'm switching my boxes over to udev and fully hotplug-driven /dev
> directories.
>
> However, that means by default I only have /dev/md0 from the MD driver,
> and if I want to "mdadm --assemble" any other array I have to manually
> create the device node for it first.
>
> Is there any chance that mdadm is going to learn how to assemble an
> array without having the device node for it already present? If so, then
> the starting of the array would get the device node created (since it
> would be a new block device) and everything would be happy...
catch-22. mdadm needed the device to pre-exist. That is how the md
driver works.
Maybe udev needs to be taught to be more open minded about these
things.
NeilBrown
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux software RAID vs. udev
2004-05-04 2:11 ` Neil Brown
@ 2004-05-04 3:06 ` Kevin P. Fleming
2004-05-04 21:26 ` Luca Berra
0 siblings, 1 reply; 4+ messages in thread
From: Kevin P. Fleming @ 2004-05-04 3:06 UTC (permalink / raw)
To: hotplug; +Cc: neilb
Neil Brown wrote:
> catch-22. mdadm needed the device to pre-exist. That is how the md
> driver works.
>
> Maybe udev needs to be taught to be more open minded about these
> things.
OK, it appears that the root cause of this problem is that udev only
creates device nodes for gendisks that have been created/registered,
because that's the only way it can learn about their existence. After
looking through the md driver, I don't even see how the first unit (md0)
is getting registered by default, unless for some reason the block layer
is calling md_probe for unit 0 without even being asked to.
Regardless, this is a big issue in the hotplug world, although it's in
no way the md driver's fault :-) In the loop driver, it just allocates
all its gendisks at init() time, which is fine when it only supports 8
(or a smallish number) of devices. However, if the md driver did that it
would allocate 512 gendisks and all the attendant md structures which
would be extremely wasteful.
Hypothetically speaking, how would you feel about a solution where the
md driver also exposed a single "control" device (character device
presumably) where mdadm could do all its machinations? Something like
the device-mapper control interface is what I'm envisioning here,
although this starts to get into the dm/md overlap area...
I'll move this discussion to the linux-hotplug list; there has to be a
solution to this problem somewhere :-)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Linux software RAID vs. udev
2004-05-04 3:06 ` Kevin P. Fleming
@ 2004-05-04 21:26 ` Luca Berra
0 siblings, 0 replies; 4+ messages in thread
From: Luca Berra @ 2004-05-04 21:26 UTC (permalink / raw)
To: linux-raid
On Mon, May 03, 2004 at 08:06:44PM -0700, Kevin P. Fleming wrote:
>Hypothetically speaking, how would you feel about a solution where the
>md driver also exposed a single "control" device (character device
>presumably) where mdadm could do all its machinations? Something like
>the device-mapper control interface is what I'm envisioning here,
>although this starts to get into the dm/md overlap area...
this seems like a nice idea to me, i never liked using md0 as a control
device.
regards,
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-05-04 21:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-01 1:25 Linux software RAID vs. udev Kevin P. Fleming
2004-05-04 2:11 ` Neil Brown
2004-05-04 3:06 ` Kevin P. Fleming
2004-05-04 21:26 ` Luca Berra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).