From: "Linda A. Walsh" <lvm@tlinx.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [linux-lvm] mount's (&udev's) dirty little naming problem
Date: Tue, 19 Jul 2011 13:46:28 -0700 [thread overview]
Message-ID: <4E25ED24.6020404@tlinx.org> (raw)
Luca Berra wrote:
> On Tue, Jul 19, 2011 at 12:57:21AM -0700, Linda A. Walsh wrote:
>> (sorry for the length of this, in advance, but I've tried to give
>> this some though...(maybe not enough/maybe too much!) ;-) )
>>
>> Luca Berra wrote:
>> > On Mon, Jul 11, 2011 at 03:16:31AM +0100, Alasdair G Kergon wrote:
>> >> The canonical name to use is /dev/<vgname>/<lvname>. ...
>> >>
>> >> [~Other forms - dm-N and /dev/mapper/X-Y are internal and ...
>> >> there'll probably be some further changes to workaround other
>> >> arbitrary udev restrictions...~]
>> >>
>> >> Different versions of df and mount haven't always retained this
>> >> preferred form for their output.
>> >>
>> > note that on a freshly installed rhel 6.1 i have this in fstab
>> >
>> > /dev/mapper/vg_candela--lv_root / ext4 ....
>>
>> ---
>>
>> Why are there two dashes between the VG&LG?
> woops, typo, sorry for that it is :
> /dev/mapper/vg_candela-lv_root / ext4 defaults 1 1
>
> L.
------
That's consistent with current behavior -- the problem is
in the current name mangling (i,e. mounts by "/dev/VG/LV" get
xlated into "/dev/mapper/<mangled-VG>-<mangled-LV>", where
at least one manglement is xlating "-" into "--". But I've already been
told that future manglements may be added due to limitations in udev.
For non LV devs, it would be like having '/dev/sdc2' xlated
into '(hd2,<rand>)' (where <rand> = some not always consistent integer)
which, of course would be silly! ( ;-) ), or xlating
LABEL="MyDisk-Label" => '/dev'disk/by-label/MYDISK--LABEL'
(with 'My-Label' being 'canonicalized', for some definition of thereof,
into some other value), vs. now, it's given the real devname
(/dev/sdc<x>) (which is FINE with me...; it's the real HW name that
the kernel uses, whereas 'label=xxx was a syntax I was encouraged
to use as part of the suse boot system, as 'everything works with labels'
(well, lets not speak about lilo, or booting from an HD w/o a ram disk,
as we'll just drop support for those options...*cough*)....
As noted, the current behavior isn't giving/using either
the 'real devname' /dev/dm-[x], NOR the user name, but a mangled name
making it the worst of all worlds, as there is no easy way to find
out the LV and VG of the device mounted on a given mount point.
To get around this == and tell me if I'm wrong, I have to use
lvm, to output a list of all VG,LV groups.
Then using a [perl] script (I suppose BASH's Associative arrays might
work too, but familiarity points toward perl at this point), I can
build up an Assoc array to map devno's -> VG,LV, then use the devno
of the mountpoint as an index into that.
That level of complexity is so completely LAME just to find out
the name I used to mount a FS on some mount point!....
If there is an easier way, please, hit me with a clue stick!
-l
reply other threads:[~2011-07-19 20:46 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4E25ED24.6020404@tlinx.org \
--to=lvm@tlinx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@redhat.com \
/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.