LVM 0.9.1 Beta6 RPMS

LVM 0.9.1 Beta6 RPMS are up on the Sistina FTP site:
ftp://ftp.sistina.com/pub/LVM/0.9.1_beta/binaries/redhat

These are based on the Connectiva LVM packages, but were created on a Redhat 6.2 system. (I think they will work on any RPM based system though...) They use a modified version of the wrapper script (it uses sed instead of basename and the libary name has changed). You need to grab at a minimum, the lvm-base, lvm-iop10, and lvm-iop10-lib packages.

This should be considered a Beta version of the package as well as of LVM. Please don't go using these on your production system and then complain because they clobber your system. I'm putting these out there for people to test so we have them right when we release a production version of LVM.

Debian packages are next in line. Hopefully I'll have those done by the end of Monday...

Go forth and test!

AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: [email protected]
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----------------------------------------
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro help desk.
-----End Obligatory Humorous Quote------------------------------------------

Would you consider releasing kernel patches against the 2.4.x
series kernels?

I want to upgrade to 2.4.x someday soon. I currently use LVM on
my system, but my confusion over exactly what patches I need to apply prevents me from upgrading to 2.4.x.

Have fun (if at all possible),

The best we can hope for concerning the people at large is that they
be properly armed.  -- Alexander Hamilton
-- Eric Hopper ([email protected] http://www.omnifarious.org/~hopper) --

Read LVM/PATCHES/README, it will explain how to generate a patch for your kernel.

- Joe

Actually, the LVM CVS (and I assume tarball as well) is fairly well set up to handle this. Since it is a lot of work to maintain patches against every kernel (consider each pre, ac kernel also). They rather ship the whole lvm*.[ch]. If you are compiling as a module, you shuld be able to compile directly in LVM/kernel (pending a patch that was posted today).

You can also run "make" in PATCHES, and it will build appropriate patches for your current kernel, to be applied to the kernel source.

Generally, the current LVM kernel code will work properly with the current tools. On occasion, the current tools will not work with an older kernel (or vice versa). It is my opinion that we should treat that as a bug to be fixed, until such a time we really need to increase the IOP version, at which point the kernel/tools will refuse to work with older code.

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

OK. That makes sense. Trying to decide if that's a good way to
do it or not. I guess its easier for brand new users, and so that's a good thing. I'm expecting different because of how reiserfs does things and previous experience with LVM. :-)

It seems to me like newer versions of the tools should work with
older kernel code up to a certain number of versions back.

Thanks,

The best we can hope for concerning the people at large is that they
be properly armed.  -- Alexander Hamilton
-- Eric Hopper ([email protected] http://www.omnifarious.org/~hopper) --

This is what the lvm-iop10-patchgen package is for. It contains a tarball with the patch generation code in it. Read the README in the main source tree when you untar it and follow the instructions to generate a patch. Let me know if you have any questions about how it works.

AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: [email protected]
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----------------------------------------
Sleep: A completely inadequate substitute for caffeine
-----End Obligatory Humorous Quote------------------------------------------

I suspect that this has been covered before, but after searching through the FAQ and the mailing list archives I haven't found a good answer.

I have a single logical volume configured on my system. I'm running 2.4.2 w/ lvm 0.9.1beta6, devfs, and SGI's xfs patches. /proc/partition looks like this (I've only included the first four columns for brevity):

9 0 8887040 md0
58 0 8884224 lvma
8 0 4444462 scsi/host0/bus0/target1/lun0/disc
8 16 4444462 scsi/host0/bus0/target2/lun0/disc
[...]

The problem here is obvious -- there isn't a device file, anywhere, called 'lvma'. There is, on the other hand, /dev/vg0/vol0. Would making the value displayed in /proc/partitions match the (devfs) device node require significant work?

Incidentally, you'll not that the raid code has the same problem -- "md0" should be "md/0", but at least with the md stuff it's possible to automatically create compatability entries in /dev.

Other than that, my xfs on top of LVM on top of raid5 has been working smoothly now for several days. Great work!

-- Lars

Lars Kellogg-Stedman <[email protected]>

The problem is not directly with LVM, but with the fact that Linus doesn't like the way that LVM set the device name (I don't know why, really). In any case, there is code in the 2.2 LVM patch which lets you enable LVM_NAME and sets the name, but it needs some code in genhd.c or similar to work. It is totally a "clean code" issue and not a technical one. Maybe one of the Sistina folk will add the LVM_NAME part back as a patch fragment for 2.4?

There was another patch floating around to re-work the device naming, but I can't find it right now. I'm not sure if anyone has made an effort to get that patch in to Linus at all. It was somewhat nicer than the LVM_NAME code, as it allowed each block device to generate its own names (a good idea, IMHO).

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Yeah -- bummer that !
I assume it'll be sorted out by the kernel HACKers, but til then, you may care for a HACK I have for devfs. If you add to /dev/devfsd.conf (or whatever)
LOOKUP ^lvm.$ EXECUTE /choose/your/path/makedev $devname $mntpnt
and then have in /choose/your/path/makedev a script which does a mknod e.g.

#! /bin/sh
# $Header: $
#
# Script to be called by devfsd via /etc/devfsd.conf and /etc/devfsd.cl

# to ensure /dev/mouse, /dev/lvma, etc. exists if it is missing ...

# (echo $0: $1 and $2) >> /tmp/m-l
case "$1" in
mouse) val=cat /etc/sysconfig/$1

	case "$val" in
	*PS*|*ps*)				res=psaux;;
	*ms*|*MS*|*microsoft*|*icrosoft*)	res=ttyS0;;
	esac
	case "$res" in ?*) ln -s $res $2/$1;; esac
	;;
cdrom)
	test -r $2/cd0 && ln -s cd0 $2/$1
	;;
cd[0-9])
	num=`echo $1 | sed 's/cd//'`
	test -r $2/cdroms/cdrom$num && ln -s cdroms/cdrom$num $2/$1
	;;
lvm*)	major=58
	# How *should* this be done ???
	case "$1" in
	lvma)	minor=0;;
	lvmb)	minor=1;;
	lvmc)	minor=2;;
	lvmd)	minor=3;;
	lvme)	minor=4;;
	lvmf)	minor=5;;
	lvmg)	minor=6;;
	lvmh)	minor=7;;
	lvmi)	minor=8;;
	lvmj)	minor=9;;
	lvmk)	minor=10;;
	*)	exit 1;;
	esac
	mknod $2/$1 b $major $minor
	;;

esac