patches for mdadm 1.8.0 (auto=dev and stacking of devices)

patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Luca Berra]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

hello,
i attach two patches for mdadm 1.8.0

the first one adds an auto=dev parameter
rationale: udev does not create /dev/md* device files, so we need a way
to create them when assembling the md device.
auto=yes allocates the first free minor number, so mdadm -A --auto=yes
/dev/md2 .... yelds a weird result if /dev/md2 is the first device
created (it would use 0 as minor)
here comes auto=dev which would use the standard minor number for
/dev/md2.

the second one fixes creation of stacked devices.
it adds a missing close(mdfd) in mdadm.c that caused 
the BLKGETSIZE64 ioctl in load_super to fail if the device was created
in the same mdadm run. (* This is very important to fix *)

It also modifies load_conffile in config.c to recreate the device list
at each run if "partition" is given as config file or appears in a
DEVICE line. This allows "DEVICE partition" to consider md devices
created during the same run of mdadm, removing the need to add
"/dev/md??" to the DEVICE line to enable stacked devices.

Regards,
L.


-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

[-- Attachment #2: mdadm-1.8.0-autodev.patch.bz2 --]
[-- Type: application/octet-stream, Size: 2462 bytes --]

[-- Attachment #3: mdadm-1.8.0-stacked.patch.bz2 --]
[-- Type: application/octet-stream, Size: 1070 bytes --]

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Lars Marowsky-Bree]

On 2005-01-23T16:13:05, Luca Berra <bluca@comedia.it> wrote:

> the first one adds an auto=dev parameter
> rationale: udev does not create /dev/md* device files, so we need a way
> to create them when assembling the md device.

Am I missing something but shouldn't this be fixed by having udev +
hotplug create the /dev entry correctly?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Peter T. Breuer]

Lars Marowsky-Bree <lmb@suse.de> wrote:
> On 2005-01-23T16:13:05, Luca Berra <bluca@comedia.it> wrote:
> 
> > the first one adds an auto=dev parameter
> > rationale: udev does not create /dev/md* device files, so we need a way
> > to create them when assembling the md device.
> 
> Am I missing something but shouldn't this be fixed by having udev +
> hotplug create the /dev entry correctly?

:-)

I mussht find out shabout udev b'fre it goesh away.

I didn't realize that hotplug could get involved. Will block.agent do
that kind of trick if I ask it to? Must experiment. 

Nice idea.

Peer

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Michael Tokarev]

Lars Marowsky-Bree wrote:
> On 2005-01-23T16:13:05, Luca Berra <bluca@comedia.it> wrote:
> 
>>the first one adds an auto=dev parameter
>>rationale: udev does not create /dev/md* device files, so we need a way
>>to create them when assembling the md device.
> 
> Am I missing something but shouldn't this be fixed by having udev +
> hotplug create the /dev entry correctly?

There's a chicken-n-eggs problem here.  In order for mdadm to create
an md device (so it will be noticed by udev/hotplug), it have to open
the control device, which, in case of md, is just any /dev/mdN.  But
before first array gets assembled, there's NO mdN entries in /dev.

mdadm tries to open /dev/md1 to get control interface, which isn't
created automatically. When an array actually gets created, it will
be noticied by hotplug/udev as it should be (provided everything is
set up correctly ofcourse).

BTW, is there a real need to do that?  In theory, one might just
create the necessary /dev/md1 from within startup script...

/mjt

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Luca Berra]

On Sun, Jan 23, 2005 at 07:46:29PM +0300, Michael Tokarev wrote:
>Lars Marowsky-Bree wrote:
>>On 2005-01-23T16:13:05, Luca Berra <bluca@comedia.it> wrote:
>>
>>>the first one adds an auto=dev parameter
>>>rationale: udev does not create /dev/md* device files, so we need a way
>>>to create them when assembling the md device.
>>
>>Am I missing something but shouldn't this be fixed by having udev +
>>hotplug create the /dev entry correctly?
>
>There's a chicken-n-eggs problem here.  In order for mdadm to create
>an md device (so it will be noticed by udev/hotplug), it have to open
>the control device, which, in case of md, is just any /dev/mdN.  But
>before first array gets assembled, there's NO mdN entries in /dev.
exactly

>mdadm tries to open /dev/md1 to get control interface, which isn't
>created automatically. When an array actually gets created, it will
>be noticied by hotplug/udev as it should be (provided everything is
>set up correctly ofcourse).

I believe the correct solution to this would be implementing a char-misc
/dev/mdadm device that mdadm would use instead of the block device,
like device-mapper does. Alas i have no time for this in the forseable
future.

>BTW, is there a real need to do that?  In theory, one might just
>create the necessary /dev/md1 from within startup script...
I would have done it in a script if --auto was not implemented, the
changes to have auto=dev are not big, mostly man page and indenting.

Regards,
L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Peter T. Breuer]

Luca Berra <bluca@comedia.it> wrote:
> I believe the correct solution to this would be implementing a char-misc
> /dev/mdadm device that mdadm would use instead of the block device,
> like device-mapper does. Alas i have no time for this in the forseable
> future.

It's a generic problem (or non-problem) - there's nothing wrong with
mdadm needing a special device file nor with the driver allowing ioctls
on any of the minors.  Device files have traditionally always been
supplied with the o/s, so it is the duty of an install script to make
them if they will or might be needed later.

And in the absence of an install script, a boot script.

Making special device files "on demand" requires the cooperation of the
driver and devfs (and since udev apparently replaces devfs, udev). One
would need to add the code to the driver.

> >BTW, is there a real need to do that?  In theory, one might just
> >create the necessary /dev/md1 from within startup script...
> I would have done it in a script if --auto was not implemented, the
> changes to have auto=dev are not big, mostly man page and indenting.

I'm not sure I follow that. If I understand you, --auto was what you
added to mdadm to make the special device files.

Personally I would prefer there to be no unannounced making of device
files, but yours is an extra flag so it does no harm in that sense.
However, I think it is a mistaken addition.  You can see that by asking
yourself why EVERY control utility does not have that option in it.
Hdparm?  Fdisk?

The answer is: because it's (a) silly, (b) none of its business. And
the same applies here. If the sysadmin does not want a dev file, then
let him be. If he wants one, let him make it.

However, as a matter of convenience, I would prefer that the driver
made the devices in /dev or /sys or wherever if it can. I don't recall
if the code is there or not!

Is there a udev document anywhere? I searched in 2.6.8.1 and found
nothing (I won't burden you with the details of my obviously too
cursory search).


Peter

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Luca Berra]

On Sun, Jan 23, 2005 at 07:52:53PM +0100, Peter T. Breuer wrote:
>Luca Berra <bluca@comedia.it> wrote:
>> I believe the correct solution to this would be implementing a char-misc

<snip>

>Making special device files "on demand" requires the cooperation of the
>driver and devfs (and since udev apparently replaces devfs, udev). One
>would need to add the code to the driver.

devfs just created 256 /dev/md/<minor> entries, and that was obnoxyous,
besides now we have mdp devices, and one of the aims of udev was
avoiding /dev pollution with un-needed nodes.

>> >BTW, is there a real need to do that?  In theory, one might just
>> >create the necessary /dev/md1 from within startup script...
>> I would have done it in a script if --auto was not implemented, the
>> changes to have auto=dev are not big, mostly man page and indenting.
>
>I'm not sure I follow that. If I understand you, --auto was what you
>added to mdadm to make the special device files.
nope,
--auto was added by Neil some time ago, it is mostly needed for mdp
devices, i just added the "dev" option to --auto.

>Personally I would prefer there to be no unannounced making of device
>files, but yours is an extra flag so it does no harm in that sense.
>However, I think it is a mistaken addition.  You can see that by asking
>yourself why EVERY control utility does not have that option in it.
>Hdparm?  Fdisk?
>
>The answer is: because it's (a) silly, (b) none of its business. And
>the same applies here. If the sysadmin does not want a dev file, then
>let him be. If he wants one, let him make it.
you should have told Neil back then.

>However, as a matter of convenience, I would prefer that the driver
>made the devices in /dev or /sys or wherever if it can. I don't recall
>if the code is there or not!
yes, but then you would need the char device trick.

>Is there a udev document anywhere? I searched in 2.6.8.1 and found
>nothing (I won't burden you with the details of my obviously too
>cursory search).
>
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Peter T. Breuer]

Luca Berra <bluca@comedia.it> wrote:
> On Sun, Jan 23, 2005 at 07:52:53PM +0100, Peter T. Breuer wrote:
> >Making special device files "on demand" requires the cooperation of the
> >driver and devfs (and since udev apparently replaces devfs, udev). One
> >would need to add the code to the driver.
> 
> devfs just created 256 /dev/md/<minor> entries, and that was obnoxyous,

It wasn't devfs - it was md, if anyone. One added calls to the drivers
to make devfs devices (well, I suppose some are made in other places
than the driver and I haven't checked what happens in md, but that is
the place the calls to make the devfs stuff would normally go).

If md makes too many for your taste, then you could submit a patch.  It
would entail doing the making as each md device is started, as opposed
to when the driver is loaded.  But as you noted there is a chicken/egg
problem.  To start md1 you have to run mdrun /dev/md1 (or whatever).

Fortunately, I think I recall that mdadm at least falls back to
/dev/md0 if it can't find md1, on the basis that any device will do for
the ioctls. I may be wrong.


> besides now we have mdp devices, and one of the aims of udev was
> avoiding /dev pollution with un-needed nodes.

I know nothing at all about udev. devfs I know most things about :).
One of the aims of devfs was to avoid unneeded entries in /dev/. I
therefore will assume that my knowledge of devfs translates to the
present case too, in the context of your comment, and say that well,
then you have to patch the driver to make the devices more
parsimoniously.

That combined with mdadm falling back to using /dev/md0 should be OK.
(I am not distinguishing between /dev/md/0 and /dev/md0 because I
don't care about the name!).

BTW - can I put in a plea for individual directories in /sys/whatever
for the controls for each device? I will want to control each device 
individually and at the moment there is no opportunity for a
non-invasive patch.

> >> >BTW, is there a real need to do that?  In theory, one might just
> >> >create the necessary /dev/md1 from within startup script...
> >> I would have done it in a script if --auto was not implemented, the
> >> changes to have auto=dev are not big, mostly man page and indenting.
> >
> >I'm not sure I follow that. If I understand you, --auto was what you
> >added to mdadm to make the special device files.
> nope,
> --auto was added by Neil some time ago, it is mostly needed for mdp
> devices, i just added the "dev" option to --auto.

OK.

> >Personally I would prefer there to be no unannounced making of device
> >files, but yours is an extra flag so it does no harm in that sense.
> >However, I think it is a mistaken addition.  You can see that by asking
> >yourself why EVERY control utility does not have that option in it.
> >Hdparm?  Fdisk?
> >
> >The answer is: because it's (a) silly, (b) none of its business. And
> >the same applies here. If the sysadmin does not want a dev file, then
> >let him be. If he wants one, let him make it.
> you should have told Neil back then.

Shrug.

> >However, as a matter of convenience, I would prefer that the driver
> >made the devices in /dev or /sys or wherever if it can. I don't recall
> >if the code is there or not!
> yes, but then you would need the char device trick.

No - you can make /dev/md0 at driver startup, let mdadm fall back to
using it (I think it does), and make the rest on device startup.

> >Is there a udev document anywhere? I searched in 2.6.8.1 and found
> >nothing (I won't burden you with the details of my obviously too
> >cursory search).
> >
> ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug

Uh, yuh. Thanks.

Peter

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Neil Brown]

On Sunday January 23, bluca@comedia.it wrote:
> hello,
> i attach two patches for mdadm 1.8.0

Thanks. These look quite reasonable.  Hopefully you will see them in a
1.9.0 in a couple of weeks (I'm not completely back from summer
holidays yet...)

NeilBrown

Re: patches for mdadm 1.8.0 (auto=dev and stacking of devices)

[Luca Berra]

On Mon, Jan 24, 2005 at 04:06:53PM +1100, Neil Brown wrote:
>On Sunday January 23, bluca@comedia.it wrote:
>> hello,
>> i attach two patches for mdadm 1.8.0
>
>Thanks. These look quite reasonable.  Hopefully you will see them in a
>1.9.0 in a couple of weeks (I'm not completely back from summer
>holidays yet...)
>
ok, i nearly forgot it is summer there,
btw if 1.9.0 will be based on 1.8.1 also review the patches i sent for
1.8.1 some time ago.

regards,
L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \