From: Michael Tokarev <mjt@tls.msk.ru>
To: Neil Brown <neilb@suse.de>
Cc: Luca Berra <bluca@comedia.it>,
Linux RAID Mailing List <linux-raid@vger.kernel.org>
Subject: Re: [PATCH] enable auto=yes by default when using udev
Date: Tue, 04 Jul 2006 14:29:10 +0400 [thread overview]
Message-ID: <44AA42F6.8070307@tls.msk.ru> (raw)
In-Reply-To: <17576.21342.685662.432117@cse.unsw.edu.au>
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
next prev parent reply other threads:[~2006-07-04 10:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-02 22:45 [PATCH] enable auto=yes by default when using udev Luca Berra
2006-07-02 23:14 ` Neil Brown
2006-07-02 23:29 ` Jason Lunz
2006-07-03 9:11 ` Mario 'BitKoenig' Holbe
2006-07-03 10:56 ` David Greaves
2006-07-03 11:13 ` Frank Blendinger
2006-07-03 22:46 ` Luca Berra
2006-07-04 10:43 ` Luca Berra
2006-07-04 10:29 ` Michael Tokarev [this message]
2006-07-04 10:47 ` Luca Berra
2006-07-04 12:19 ` Mario 'BitKoenig' Holbe
2006-07-18 5:19 ` Neil Brown
2006-07-18 10:07 ` Christian Pernegger
2006-07-17 19:42 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44AA42F6.8070307@tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=bluca@comedia.it \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.