Linux software RAID vs. udev

Linux software RAID vs. udev

[Kevin P. Fleming]

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)

Re: Linux software RAID vs. udev

[Neil Brown]

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

Re: Linux software RAID vs. udev

[Kevin P. Fleming]

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

Re: Linux software RAID vs. udev

[Kevin P. Fleming]

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 :-)

Re: Linux software RAID vs. udev

[Neil Brown]

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

Re: Linux software RAID vs. udev

[Kevin P. Fleming]

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

Re: Linux software RAID vs. udev

[Olaf Hering]

 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

Re: Linux software RAID vs. udev

[Luca Berra]

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
 / \

Re: Linux software RAID vs. udev

[Neil Brown]

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