All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev and md/dm
Date: Sat, 16 Jun 2007 07:31:32 +0000	[thread overview]
Message-ID: <20070616073132.GA3762@tasint.org> (raw)
In-Reply-To: <20070616002057.GI20024@tasint.org>

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.
	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.  But the udev rules skip
checking uuids and labels on the aggregate devices.
	Please, show me where I'm wrong :-)


Joel

-- 

"The question of whether computers can think is just like the question
 of whether submarines can swim."
	- Edsger W. Dijkstra

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

-------------------------------------------------------------------------
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

  parent reply	other threads:[~2007-06-16  7:31 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 [this message]
2007-06-16  7:49 ` Andrey Borzenkov
2007-06-16  8:46 ` Alexander E. Patrakov
2007-06-16 10:40 ` Kay Sievers
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=20070616073132.GA3762@tasint.org \
    --to=joel.becker@oracle.com \
    --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 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.