[linux-lvm] lvm-1.0.1rc1 cvs snapshot and devfs

[AJ Lewis]

On Sat, Aug 25, 2001 at 07:37:49PM +0200, Arkadiusz Miskiewicz wrote:
> I'm using 2.4.7/x86 kernel with xfs, devfs and LVM version
> 1.0.1-rc1(17/08/2001). Unfortunately devfs support isn't nice.
> 
> Simple example (/dev/hdc5 is Linux-LVM partition (8e))
> 
> [root at arm misiek]# pvcreate /dev/hdc5
> pvcreate -- physical volume "/dev/hdc5" successfully created
> 
> [root at arm misiek]# vgextend storage /dev/hdc5
> vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
> vgextend -- ERROR: no physical volumes usable to extend volume group "storage"
> 
> [root at arm misiek]# ls -l /dev/hdc5
> lr-xr-xr-x    1 root     root           33 sie 25  2001 /dev/hdc5 -> ide/host0/bus1/target0/lun0/part5
> [root at arm misiek]# vgextend storage /dev/ide/host0/bus1/target0/lun0/part5
> vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
> vgextend -- doing automatic backup of volume group "storage"
> vgextend -- volume group "storage" successfully extended
> 
> [root at arm misiek]# 
> 
> So LVM tools are working fine with real devfs device names while some
> tools don't work with old non-devfs names (vgextend and other vg*).
> 
> IMHO simplest solution is inside LVM use real devfs names - always (or
> only when devfs is in kernel and is used/mounted by user) call
> readlink(2) on device specified by user on command line.

First off, this is a known issue that has been discussed a bit on the list
and quite a bit internally between the LVM developers.

As far as using readlink on the device: that's what I thought too, until I
actually looked at the code involved.  It's actually much more complicated
than that due to the way the lvm_dir_cache.c code is being called and used.
Basically, fixing the symlink issue would either involve a complete rewrite
of the LVM library code involved, or a complete rewrite of the tools and the
library code involved, depending upon how you went about it.  This is not a
trivial task.

The experimental branch has the beginnings of the Device Manager which is a
rewrite/redesign of lvm_dir_cache.  This will be used in future versions of
LVM and will enable much more sane discovery and caching of devices than
the current method.

If anyone has patches they'd like to submit to fix this in all the LVM
tools, we'd definitely welcome it, but for the moment the answer is to fully
specify the true devfs paths when using the LVM tools.

Regards,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-638-0500
1313 5th St SE, Suite 111              Fax:    612-638-0500
Minneapolis, MN 55414                  E-Mail: lewis at sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-----Begin Obligatory Humorous Quote----------------------------------------
665.9238429876 - Number of the Pentium Beast
-----End Obligatory Humorous Quote------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20010826/cafbd53d/attachment.sig>