From: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>
To: hotplug <linux-hotplug-devel@lists.sourceforge.net>
Cc: neilb@cse.unsw.edu.au
Subject: Re: Linux software RAID vs. udev
Date: Tue, 04 May 2004 03:06:44 +0000 [thread overview]
Message-ID: <409708C4.6070905@backtobasicsmgmt.com> (raw)
In-Reply-To: <16534.64452.67783.81354@cse.unsw.edu.au>
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 :-)
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_idÅ66&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next parent reply other threads:[~2004-05-04 3:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4092FCA6.2020103@backtobasicsmgmt.com>
[not found] ` <16534.64452.67783.81354@cse.unsw.edu.au>
2004-05-04 3:06 ` Kevin P. Fleming [this message]
2004-05-04 3:49 ` Linux software RAID vs. udev Neil Brown
2004-05-04 3:59 ` Kevin P. Fleming
2004-05-04 7:27 ` Olaf Hering
2004-05-11 4:22 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=409708C4.6070905@backtobasicsmgmt.com \
--to=kpfleming@backtobasicsmgmt.com \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=neilb@cse.unsw.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).