[PATCH] enable auto=yes by default when using udev

[PATCH] enable auto=yes by default when using udev

[Luca Berra]

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

Hello,
the following patch aims at solving an issue that is confusing a lot of
users.
when using udev, device files are created only when devices are
registered with the kernel, and md devices are registered only when
started.
mdadm needs the device file _before_ starting the array.
so when using udev you must add --auto=yes to the mdadm commandline or
to the ARRAY line in mdadm.conf

following patch makes auto=yes the default when using udev

L.


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

[-- Attachment #2: mdadm-2.5.1-autof.patch --]
[-- Type: text/plain, Size: 896 bytes --]

* Sat Jun 24 2006 Luca Berra <bluca@vodka.it>
- automatically create devices if using udev

--- mdadm-2.5.1/mdadm.c.autof	2006-06-02 01:51:01.000000000 -0400
+++ mdadm-2.5.1/mdadm.c	2006-06-24 05:17:45.000000000 -0400
@@ -857,6 +857,13 @@
 		fputs(Usage, stderr);
 		exit(2);
 	}
+
+	/* if we are using udev and auto is not set, mdadm will almost
+	 * certainly fail, so we force it here.
+	 */
+	if (autof == 0 && access("/dev/.udevdb",F_OK) == 0)
+		autof=2;
+
 	/* Ok, got the option parsing out of the way
 	 * hopefully it's mostly right but there might be some stuff
 	 * missing
@@ -873,7 +880,7 @@
 			fprintf(stderr, Name ": an md device must be given in this mode\n");
 			exit(2);
 		}
-		if ((int)ident.super_minor == -2 && autof) {
+		if ((int)ident.super_minor == -2 && autof > 2 ) {
 			fprintf(stderr, Name ": --super-minor=dev is incompatible with --auto\n");	
 			exit(2);
 		}

Re: [PATCH] enable auto=yes by default when using udev

[Neil Brown]

On Monday July 3, bluca@comedia.it wrote:
> Hello,
> the following patch aims at solving an issue that is confusing a lot of
> users.
> when using udev, device files are created only when devices are
> registered with the kernel, and md devices are registered only when
> started.
> mdadm needs the device file _before_ starting the array.
> so when using udev you must add --auto=yes to the mdadm commandline or
> to the ARRAY line in mdadm.conf
> 
> following patch makes auto=yes the default when using udev
> 

The principle I'm reasonably happy with, though you can now make this
the default with a line like

  CREATE auto=yes
in mdadm.conf.

However....

> +
> +	/* if we are using udev and auto is not set, mdadm will almost
> +	 * certainly fail, so we force it here.
> +	 */
> +	if (autof == 0 && access("/dev/.udevdb",F_OK) == 0)
> +		autof=2;
> +

I'm worried that this test is not very robust.
On my Debian/unstable system running used, there is no
 /dev/.udevdb
though there is a
 /dev/.udev/db

I guess I could test for both, but then udev might change
again.... I'd really like a more robust check.

Maybe I could test if /dev was a mount point?

Any other ideas?

NeilBrown

Re: [PATCH] enable auto=yes by default when using udev

[Jason Lunz]

neilb@suse.de said:
> Maybe I could test if /dev was a mount point?
> Any other ideas?

there's a udevd you can check for. I don't know whether that's a better
test or not.

Jason

Re: [PATCH] enable auto=yes by default when using udev

[Mario 'BitKoenig' Holbe]

Jason Lunz <lunz@falooley.org> wrote:
> there's a udevd you can check for. I don't know whether that's a better
> test or not.

It's not. For example, the Debian package does also start this udevd on
package upgrades, even when a 2.4 kernel is running which definitely
has no udev support :)


regards
   Mario
-- 
Programmieren in C++ haelt die grauen Zellen am Leben. Es schaerft
alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den
Unsinn und den Stumpfsinn.
                                 [Holger Veit in doc]

Re: [PATCH] enable auto=yes by default when using udev

[David Greaves]

Neil Brown wrote:
> I guess I could test for both, but then udev might change
> again.... I'd really like a more robust check.
> 
> Maybe I could test if /dev was a mount point?

IIRC you can have diskless machines with a shared root and nfs mounted
static /dev/

David

-- 

Re: [PATCH] enable auto=yes by default when using udev

[Frank Blendinger]

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

On Mon, Jul 03, 2006 at 09:14:38AM +1000, Neil Brown wrote:
> I'm worried that this test is not very robust.
> On my Debian/unstable system running used, there is no
>  /dev/.udevdb
> though there is a
>  /dev/.udev/db
> 
> I guess I could test for both, but then udev might change
> again.... I'd really like a more robust check.
> 
> Maybe I could test if /dev was a mount point?
> 
> Any other ideas?

Maybe checking for a running 'udevd' process?


Frank

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A
   "Just because I don't care doesn't mean I don't undestand."
                                               (Homer Simpson)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] enable auto=yes by default when using udev

[Luca Berra]

On Mon, Jul 03, 2006 at 09:14:38AM +1000, Neil Brown wrote:
>However....
>
>> +
>> +	/* if we are using udev and auto is not set, mdadm will almost
>> +	 * certainly fail, so we force it here.
>> +	 */
>> +	if (autof == 0 && access("/dev/.udevdb",F_OK) == 0)
>> +		autof=2;
>> +
>
>I'm worried that this test is not very robust.
>On my Debian/unstable system running used, there is no
> /dev/.udevdb
>though there is a
> /dev/.udev/db
>
>I guess I could test for both, but then udev might change
>again.... I'd really like a more robust check.
>
is /dev/.udev/db a debianism?
in this case a check for both might suffice, else i will have to think
harder about it.

L.

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

Re: [PATCH] enable auto=yes by default when using udev

[Luca Berra]

On Tue, Jul 04, 2006 at 12:46:03AM +0200, Luca Berra wrote:
>On Mon, Jul 03, 2006 at 09:14:38AM +1000, Neil Brown wrote:
>>However....
>>
>>>+
>>>+	/* if we are using udev and auto is not set, mdadm will almost
>>>+	 * certainly fail, so we force it here.
>>>+	 */
>>>+	if (autof == 0 && access("/dev/.udevdb",F_OK) == 0)
>>>+		autof=2;
>>>+
>>
>>I'm worried that this test is not very robust.
>>On my Debian/unstable system running used, there is no
>>/dev/.udevdb
>>though there is a
>>/dev/.udev/db
>>
>>I guess I could test for both, but then udev might change
>>again.... I'd really like a more robust check.
>>
>is /dev/.udev/db a debianism?
no it is not
>in this case a check for both might suffice, else i will have to think
>harder about it.

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

Re: [PATCH] enable auto=yes by default when using udev

[Michael Tokarev]

Neil Brown wrote:
> On Monday July 3, bluca@comedia.it wrote:
>> Hello,
>> the following patch aims at solving an issue that is confusing a lot of
>> users.
>> when using udev, device files are created only when devices are
>> registered with the kernel, and md devices are registered only when
>> started.
>> mdadm needs the device file _before_ starting the array.
>> so when using udev you must add --auto=yes to the mdadm commandline or
>> to the ARRAY line in mdadm.conf
>>
>> following patch makes auto=yes the default when using udev
> 
> The principle I'm reasonably happy with, though you can now make this
> the default with a line like
> 
>   CREATE auto=yes
> in mdadm.conf.
> 
> However....
> 
>> +
>> +	/* if we are using udev and auto is not set, mdadm will almost
>> +	 * certainly fail, so we force it here.
>> +	 */
>> +	if (autof == 0 && access("/dev/.udevdb",F_OK) == 0)
>> +		autof=2;
>> +
> 
> I'm worried that this test is not very robust.
> On my Debian/unstable system running used, there is no
>  /dev/.udevdb
> though there is a
>  /dev/.udev/db
> 
> I guess I could test for both, but then udev might change
> again.... I'd really like a more robust check.

Why to test for udev at all?  If the device does not exist, regardless
if udev is running or not, it might be a good idea to try to create it.
Because IT IS NEEDED, period.  Whenever the operation fails or not, and
whenever we fail if it fails or not - it's another question, and I think
that w/o explicit auto=yes, we may ignore create error and try to continue,
and with auto=yes, we fail on create error.

Note that /dev might be managed by some other tool as well, like mudev
from busybox, or just a tiny shell /sbin/hotplug script.

Note also that the whole root filesystem might be on tmpfs (like in
initramfs), so /dev will not be a mountpoint.

Also, I think mdadm should stop creating strange temporary nodes somewhere
as it does now.  If /dev/whatever exist, use it. If not, create it (unless,
perhaps, auto=no is specified) directly with proper mknod("/dev/mdX"), but
don't try to use some temporary names in /dev or elsewhere.

In case of nfs-mounted read-only root filesystem, if someone will ever need
to assemble raid arrays in that case.. well, he can either prepare proper
/dev on the nfs server, or use tmpfs-based /dev, or just specify /tmp/mdXX
instead of /dev/mdXX - whatever suits their needs better.

/mjt

Re: [PATCH] enable auto=yes by default when using udev

[Luca Berra]

On Tue, Jul 04, 2006 at 02:29:10PM +0400, Michael Tokarev wrote:
>Why to test for udev at all?  If the device does not exist, regardless
because udev whas what was giving me pains :)

>if udev is running or not, it might be a good idea to try to create it.
>Because IT IS NEEDED, period.  Whenever the operation fails or not, and
i believe we can set autof to 2 by default.

>whenever we fail if it fails or not - it's another question, and I think
>that w/o explicit auto=yes, we may ignore create error and try to continue,
>and with auto=yes, we fail on create error.
we need to distinguish between explicit auto=no, explicit auto=yes and
implicit auto=yes for this. maybe this is overkill

>as it does now.  If /dev/whatever exist, use it. If not, create it (unless,
>perhaps, auto=no is specified) directly with proper mknod("/dev/mdX"), but
>don't try to use some temporary names in /dev or elsewhere.
agreed!

L.

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

Re: [PATCH] enable auto=yes by default when using udev

[Mario 'BitKoenig' Holbe]

Michael Tokarev <mjt@tls.msk.ru> wrote:
> Why to test for udev at all?  If the device does not exist, regardless
> if udev is running or not, it might be a good idea to try to create it.
> Because IT IS NEEDED, period.  Whenever the operation fails or not, and

Perhaps it was just a typo and you damage more if you just create it.
Typical behaviour is to *not* just create device nodes because they
don't exist but instead assume administrators know what they do.
That's why I personally think it's better to rely on administrator's
decision about automatic creation of device nodes.


regards
   Mario
-- 
As a rule, the more bizarre a thing is, the less mysterious it proves to be.
                                    -- Sherlock Holmes by Arthur Conan Doyle

Re: [PATCH] enable auto=yes by default when using udev

[Neil Brown]

On Tuesday July 4, Mario.Holbe@TU-Ilmenau.DE wrote:
> Michael Tokarev <mjt@tls.msk.ru> wrote:
> > Why to test for udev at all?  If the device does not exist, regardless
> > if udev is running or not, it might be a good idea to try to create it.
> > Because IT IS NEEDED, period.  Whenever the operation fails or not, and
> 
> Perhaps it was just a typo and you damage more if you just create it.
> Typical behaviour is to *not* just create device nodes because they
> don't exist but instead assume administrators know what they do.
> That's why I personally think it's better to rely on administrator's
> decision about automatic creation of device nodes.

Yes, the typo issue is a real one.  But so is the frustration with
devices not appearing where you would expect.

I think I'm leaning towards auto-creating names if they look like
standard names (or are listed in mdadm.conf?), but required
auto=whatever to create anything else.

NeilBrown

Re: [PATCH] enable auto=yes by default when using udev

[Christian Pernegger]

> I think I'm leaning towards auto-creating names if they look like
> standard names (or are listed in mdadm.conf?), but required
> auto=whatever to create anything else.

The auto= option has the disadvantage that it is different for
partitionable and regular arrays -- is there no way to detect from the
array if it is supposed to be partitionable or not?

As it is scripts are better off creating the node with correct
major/minor and assembling without auto=.

Regards,

C.

Re: [PATCH] enable auto=yes by default when using udev

[Bill Davidsen]

Michael Tokarev wrote:

>Neil Brown wrote:
>  
>
>>On Monday July 3, bluca@comedia.it wrote:
>>    
>>
>>>Hello,
>>>the following patch aims at solving an issue that is confusing a lot of
>>>users.
>>>when using udev, device files are created only when devices are
>>>registered with the kernel, and md devices are registered only when
>>>started.
>>>mdadm needs the device file _before_ starting the array.
>>>so when using udev you must add --auto=yes to the mdadm commandline or
>>>to the ARRAY line in mdadm.conf
>>>
>>>following patch makes auto=yes the default when using udev
>>>      
>>>
>>The principle I'm reasonably happy with, though you can now make this
>>the default with a line like
>>
>>  CREATE auto=yes
>>in mdadm.conf.
>>
>>However....
>>
>>    
>>
>>>+
>>>+	/* if we are using udev and auto is not set, mdadm will almost
>>>+	 * certainly fail, so we force it here.
>>>+	 */
>>>+	if (autof == 0 && access("/dev/.udevdb",F_OK) == 0)
>>>+		autof=2;
>>>+
>>>      
>>>
>>I'm worried that this test is not very robust.
>>On my Debian/unstable system running used, there is no
>> /dev/.udevdb
>>though there is a
>> /dev/.udev/db
>>
>>I guess I could test for both, but then udev might change
>>again.... I'd really like a more robust check.
>>    
>>
>
>Why to test for udev at all?  If the device does not exist, regardless
>if udev is running or not, it might be a good idea to try to create it.
>Because IT IS NEEDED, period.  Whenever the operation fails or not, and
>whenever we fail if it fails or not - it's another question, and I think
>that w/o explicit auto=yes, we may ignore create error and try to continue,
>and with auto=yes, we fail on create error.
>  
>
I have to agree here, I can't think of a case where creation of the 
device name would not be desirable, udev or no. But to be cautious, 
perhaps the default should be to create the device if the path starts 
with /dev/ or /tmp/ unless auto creation is explicitly off. I don't 
think udev or mount points come into the default decision at all, there 
are just too many options on naming.

>Note that /dev might be managed by some other tool as well, like mudev
>from busybox, or just a tiny shell /sbin/hotplug script.
>
>Note also that the whole root filesystem might be on tmpfs (like in
>initramfs), so /dev will not be a mountpoint.
>  
>
Agree with both points.

>Also, I think mdadm should stop creating strange temporary nodes somewhere
>as it does now.  If /dev/whatever exist, use it. If not, create it (unless,
>perhaps, auto=no is specified) directly with proper mknod("/dev/mdX"), but
>don't try to use some temporary names in /dev or elsewhere.
>  
>
True, but I don't see a case where this would be useful. And if it is, 
then add an auto=obscure_names option for the case where you really want 
that behaviour.

>In case of nfs-mounted read-only root filesystem, if someone will ever need
>to assemble raid arrays in that case.. well, he can either prepare proper
>/dev on the nfs server, or use tmpfs-based /dev, or just specify /tmp/mdXX
>instead of /dev/mdXX - whatever suits their needs better.
>
Because /dev and /tmp are well known special cases, I would default auto 
for them. In other cases explicit behavior could be specified.

Feel free to point out something bad which occurs by using this default 
behavior.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979