* Re: Linux software RAID vs. udev
@ 2004-05-04 3:06 ` Kevin P. Fleming
0 siblings, 0 replies; 9+ 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] 9+ messages in thread
* Re: Linux software RAID vs. udev
2004-05-04 3:06 ` Kevin P. Fleming
(?)
@ 2004-05-04 3:49 ` Neil Brown
-1 siblings, 0 replies; 9+ messages in thread
From: Neil Brown @ 2004-05-04 3:49 UTC (permalink / raw)
To: linux-hotplug
On Monday May 3, kpfleming@backtobasicsmgmt.com wrote:
> 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.
init/do_mounts_md.c:md_run_setup
>
> 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'm not totally against it, though I'm not convince it is a good idea
either.
I think it would be very poor form for udev to break established and
working semantics. If it doesn't let you pre-create devices in /dev
and have then stay there, then I think that is a mistake.
>
> I'll move this discussion to the linux-hotplug list; there has to be a
> solution to this problem somewhere :-)
NeilBrown
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Linux software RAID vs. udev
2004-05-04 3:06 ` Kevin P. Fleming
(?)
(?)
@ 2004-05-04 3:59 ` Kevin P. Fleming
-1 siblings, 0 replies; 9+ messages in thread
From: Kevin P. Fleming @ 2004-05-04 3:59 UTC (permalink / raw)
To: linux-hotplug
Neil Brown wrote:
>>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.
>
>
> init/do_mounts_md.c:md_run_setup
OK, I saw that file but disregarded it thinking it didn't apply if I
didn't have any autostart arrays. I'll look again to satisfy my
curiosity :-)
> I think it would be very poor form for udev to break established and
> working semantics. If it doesn't let you pre-create devices in /dev
> and have then stay there, then I think that is a mistake.
udev does not prevent anyone from creating any nodes in /dev they wish.
/dev is just any filesystem you want to use, you can put anything there
you like. The issue is that those of us that are converting to
hotplug-driven udev are using ramfs/tmpfs for /dev, so there is no
persistence. That means (for now) manually creating all /dev/md nodes we
might need to use during that boot, or manually creating any required
nodes before attempting to run mdadm. Neither of these are horrible
solutions, they're just not elegant :-)
Since all of this infrastructure is already in place for the dm
subsystem, I guess this leads back to implementing the md personalities
as dm targets, but that's a much larger issue. It would solve this
problem completely, though.
-------------------------------------------------------
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Linux software RAID vs. udev
2004-05-04 3:06 ` Kevin P. Fleming
` (2 preceding siblings ...)
(?)
@ 2004-05-04 7:27 ` Olaf Hering
-1 siblings, 0 replies; 9+ messages in thread
From: Olaf Hering @ 2004-05-04 7:27 UTC (permalink / raw)
To: linux-hotplug
On Tue, May 04, Neil Brown wrote:
> I think it would be very poor form for udev to break established and
> working semantics. If it doesn't let you pre-create devices in /dev
> and have then stay there, then I think that is a mistake.
How do you plan to solve the chicken/egg problem then? Just create mdN
in advance if /dev is in tmpfs?
--
USB is for mice, FireWire is for men!
sUse lINUX ag, n√úRNBERG
-------------------------------------------------------
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Ãk
_______________________________________________
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Linux software RAID vs. udev
2004-05-04 3:06 ` Kevin P. Fleming
` (3 preceding siblings ...)
(?)
@ 2004-05-04 21:26 ` Luca Berra
-1 siblings, 0 replies; 9+ 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] 9+ messages in thread* Re: Linux software RAID vs. udev
2004-05-04 3:06 ` Kevin P. Fleming
` (4 preceding siblings ...)
(?)
@ 2004-05-11 4:22 ` Neil Brown
-1 siblings, 0 replies; 9+ messages in thread
From: Neil Brown @ 2004-05-11 4:22 UTC (permalink / raw)
To: linux-hotplug
On Tuesday May 4, olh@suse.de wrote:
> On Tue, May 04, Neil Brown wrote:
>
> > I think it would be very poor form for udev to break established and
> > working semantics. If it doesn't let you pre-create devices in /dev
> > and have then stay there, then I think that is a mistake.
>
> How do you plan to solve the chicken/egg problem then? Just create mdN
> in advance if /dev is in tmpfs?
Sounds like a good plan to me.
That doesn't mean that md will never be changed to play more nicely
with udev, but it does mean that there is no need to hastily rush in.
NeilBrown
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
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
^ permalink raw reply [flat|nested] 9+ messages in thread