[linux-lvm] mount's (&udev's) dirty little naming problem -- (was Inconsistent naming...?)

[Linda A. Walsh]

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

   Does this imply some other random change (that will break the scripts
I'm developing?)... 

   There is a **need** (especially with a volume manager), vs. physical
disks, to be able to map a file-system, on a mount-point, to the device
that was mounted on that point (if any).   Similarly, there is a need to
be able to know where and if a given volume is mounted so one can
operate on it.

   Traditionally, the output from mount, or on linux, /proc/mounts, gave
a reliable method for doing the above.  With _non_- LVM devices, it
appears to still have a reliable policy of using either the user given
name, or the actual physical device name.

    Given Luca's input about further randomizations to the device listed
in /proc/mounts (and often, due to various reasons, /etc/mtab, which
many sysadmins, may have symlinked to /proc/mounts (as suggested in the
mounts manpage for efficiency and consistency).

This points back to what I believe to be the biggest :
 > On Mon, Jul 11, 2011 at 03:16:31AM +0100, Alasdair G Kergon wrote:
 >> The canonical name to use is /dev/<vgname>/<lvname>.  That's been
 >> inherited from the original LVM1 code and has never changed.
 >>
 >> ***   That's the only form of the name to use to maintain
 >> compatibility.  ***
 >>
 >> *** Other forms - dm-N and /dev/mapper/X-Y are internal and the
 >> format of those is not guaranteed ***...

----

   This problem may need to be fixed in more than one place.  But a fix
in mount (1) would be a good place to start, as it's manpage already has
some some inaccuracies in some cases regarding differences in
information between /proc/mounts, and /etc/mtab (and it's concept of
canonicalization).  It's manpage says:

      When the proc filesystem is mounted (say at  /proc),  the  files
      /etc/mtab  and /proc/mounts have very similar contents. The for‐
      mer has somewhat more(*1) information, such  as  the  mount
      options used,  but  is  not  necessarily  up-to-date  (cf. the -n
      option below). It is possible to replace /etc/mtab by a  symbolic
      link to /proc/mounts, and especially when you have very large
      numbers of mounts things will be much faster with that symlink,
      but some information is lost that way(*2), and in particular using
      the "user" option will fail.

====

   The above is not entirely accurate at best, likely is misleading:
First, regarding '*1) above, in some cases there is more information in
/proc/mounts than in /etc/mtab.  Ex:
 
   Here are the entries from /etc/fstab, /proc/mounts and /etc/mtab, (in
order) for a squid-cache partition:

a) /dev/Home+Space/Squid_Cache /var/cache/squid xfs
defaults,noatime,nodiratime,swalloc,largeio,logbsize=256k  2 0

b) /dev/mapper/Home+Space-Squid_Cache /var/cache/squid xfs
rw,noatime,nodiratime,swalloc,attr2,largeio,logbsize=256k,sunit=128,swidth=1280,noquota
0 0

c) /dev/mapper/Home+Space-Squid_Cache /var/cache/squid xfs
rw,noatime,nodiratime,swalloc,largeio,logbsize=256k 0 0

=======

   The entry in 'mtab'; doesn't look like it has "more" information.
Both places lost the mount order (not that important) and both, lose the
given device name.  Interestingly, the entry in /proc/mounts shows
details read from the filesystem about how to do I/O.

   Compare the above situation to what it does for a non LV device, like
/usr (only looking at 'fstab' vs. /proc/mounts) where I mount by label:

a) LABEL=Usr /usr xfs
defaults,noatime,nodiratime,swalloc,largeio,logbsize=256k 1 1

b) /dev/sdc6 /usr xfs
rw,noatime,nodiratime,swalloc,attr2,largeio,logbsize=256k,noquota 0 0

   I.e. - /proc/mount DOESN'T use "/dev/disk/by-label/Usr"

---

   The best way to fix this, IMO, is to fix mount's idea of 'canonical',
since /dev/mapper/<manged-VG>-<mangled-LV> is NOT canonical, either by
the standards/statements of the LVM group (i.e. /dev/VG/LV being the
only only supported constant standard) is the only offically supported
path to use), NOR by the definition that the name is not a "pseudonym"
(symlink) to the real device (i.e. /dev/mapper/xxxxx all point to 'hard'
device names of /dev/dm-[0-x].

   There is a 'no-canonical' switch to mount that could allow working
around this, but one can't expect it will have been used, by default,
when isn't (i.e. default is to create a name that someone has defined as
'canonical', but isn't by definitions I am more familiar with (using the
standardized name for the device (i.e. /dev/VG/LV, or using the actual
devname (not as friendly in this case).


   Do you think this can be fixed?

   What groups do would be involved? -- is it just 'the mount prog that
would need changing (seems too simple, but since 'the '-no-canoncal
seems to work in that it uses the value in /etc/fstab in both
/proc/mounts and in /etc/mtab, that might be a good first start.
Though it sounds like the reason why mount is confused about the
canonical name seems to step from some problem in udev -- and really
probably should be addressed as well, but unless there is already a
'non-canonical' option in udev to turn on, the framework to do so would
have to be written first.

   Am I over-focusing on this or does anyone see this a problem that is
only likely to get worse as time moves forward?

Thanks...  Linda