From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev and md/dm
Date: Sat, 16 Jun 2007 10:40:08 +0000 [thread overview]
Message-ID: <1181990408.4138.19.camel@lov.localdomain> (raw)
In-Reply-To: <20070616002057.GI20024@tasint.org>
On Sat, 2007-06-16 at 00:31 -0700, Joel Becker wrote:
> On Sat, Jun 16, 2007 at 04:32:49AM +0200, Kay Sievers wrote:
> > On 6/16/07, Joel Becker <Joel.Becker@oracle.com> wrote:
> > > Why does udev ignore md* and dm-* devices for persistent naming?
> > >I was utterly surprised to find that an ext3 on /dev/md0 or /dev/dm-0
> > >won't show up in /dev/disk/by-uuid. Given that dm and md devices can
> > >change names, isn't this something we'd really like to have?
> >
> > Sure, they just have their own rules files. Both have specific
> > requirements/lifetime-rules and plug into "change" events.
>
> I'm looking at rhel5, debian, and raw udev-105, and I can't find
> anywhere in the rules that use vol_id to map md or dm devices to
> /dev/disk/by-label and /dev/disk/by-uuid. The vol_id using files
> (persistent.rules) skips those devices. I can see why perhaps you'd say
> "loop and ramdisk may be garbage", but dm*, md*, and similar are
> expected persistent environment things. And their names can certainly
> change.
dm: (requires a simple patch to dmsetup)
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=etc/udev/suse/64-device-mapper.rules;hb=HEAD
md: (requires the latest mdadm)
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=etc/udev/suse/64-md-raid.rules;hb=HEAD
> I ask because I am looking at implementing a robust "how to
> determine what device is meant by UUID xxxxx". Robust in the face of
> catching the raid1 and multipath and so on. So /dev/disk/by-uuid/xxxxx
> wouldn't point to /dev/sdd1 if it really should be /dev/md0. I had
> hoped udev + vol_id would do this for me, as vol_id seems to have
> explicit ordering to make this work right.
Right, vol_id recognizes md-metadata and doesn't return uuid/label for
raid members.
Udev has priorities for the symlink-stack (multiple devices can claim
the same name, but only one can actually own the symlink), and the
multipath rules for dm-devices specify a higher priority, so that
symlinks requested from the individual paths are overwritten.
> But the udev rules skip
> checking uuids and labels on the aggregate devices.
> Please, show me where I'm wrong :-)
All of that is not in RHEL or Debian at the moment. :)
Kay
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
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
next prev parent reply other threads:[~2007-06-16 10:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-16 0:20 udev and md/dm Joel Becker
2007-06-16 2:32 ` Kay Sievers
2007-06-16 7:31 ` Joel Becker
2007-06-16 7:49 ` Andrey Borzenkov
2007-06-16 8:46 ` Alexander E. Patrakov
2007-06-16 10:40 ` Kay Sievers [this message]
2007-06-16 10:53 ` martin f krafft
2007-06-16 11:02 ` Kay Sievers
2007-06-16 16:50 ` Dan Nicholson
2007-06-16 17:09 ` Kay Sievers
2007-06-16 18:38 ` Joel Becker
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=1181990408.4138.19.camel@lov.localdomain \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).