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

2006-07-18 Thread 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.
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-07-17 Thread Bill Davidsen

Michael Tokarev wrote:


Neil Brown wrote:
 


On Monday July 3, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

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


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

2006-07-17 Thread Neil Brown
On Tuesday July 4, [EMAIL PROTECTED] wrote:
 Michael Tokarev [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-07-04 Thread Michael Tokarev
Neil Brown wrote:
 On Monday July 3, [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-07-04 Thread 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 -- [EMAIL PROTECTED]
   Communication Media  Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
 XAGAINST HTML MAIL
/ \
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-07-04 Thread Mario 'BitKoenig' Holbe
Michael Tokarev [EMAIL PROTECTED] 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

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


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

2006-07-03 Thread Mario 'BitKoenig' Holbe
Jason Lunz [EMAIL PROTECTED] 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]

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


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

2006-07-03 Thread 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

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


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

2006-07-03 Thread Frank Blendinger
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)


signature.asc
Description: Digital signature


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

2006-07-03 Thread 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 -- [EMAIL PROTECTED]
   Communication Media  Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
 XAGAINST HTML MAIL
/ \
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-07-02 Thread Luca Berra

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 -- [EMAIL PROTECTED]
   Communication Media  Services S.r.l.
/\
\ / ASCII RIBBON CAMPAIGN
 XAGAINST HTML MAIL
/ \
* Sat Jun 24 2006 Luca Berra [EMAIL PROTECTED]
- automatically create devices if using udev

--- mdadm-2.5.1/mdadm.c.autof   2006-06-02 01:51:01.0 -0400
+++ mdadm-2.5.1/mdadm.c 2006-06-24 05:17:45.0 -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

2006-07-02 Thread Neil Brown
On Monday July 3, [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2006-07-02 Thread Jason Lunz
[EMAIL PROTECTED] 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

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