Re: [linux-lvm] LVM support for LILO

Re: [linux-lvm] LVM support for LILO

[Andreas Dilger]

Heinz writes:
> We would need at least an additional "allocation on a single device"

The "contiguous" option to lvcreate should be enough, since the /boot LV
will be relatively small (1 or 2 PEs).  If it ever does cross two PVs,
LILO will detect this with Andi's patch, so no need to make LVM more
complicated.

Luca writes:
> beware that bios addressable might mean below cylinder 1024 if your bios
> doesn't handle lba32

LILO already checks this, since we will be passing the raw disk block numbers
to LILO, so it will be no different than a regular /boot.  The one benefit
of a full LVM system is that if you need to grow /boot, but you have a 1024
cylinder BIOS limit, you can still do this by migrating a PE of another LV
away from the end of the boot LV, and then extending the boot LV.

Heinz writes:
> ... need a "don't pvmove" status flag for the LV to ensure that no wrong
> pvmove(8) can happen.

Luca writes:
> i'd like to be able to pvmove even the boot lv (i.e. i am migrating
> to a larger disk)

As for the "don't move" status flag, this _may_ be useful, but people already
can't move their kernels out of /boot, so this is probably not that big of
an issue.  I would rather keep things simple.  It will not happen very often
that people move /boot, and with newer systems, there are fewer BIOS limits
so it may even be _more_ confusing if people can't move /boot when they want.

Cheers, Andreas

Re: [linux-lvm] LVM support for LILO

[Andreas Dilger]

Michael Kellen writes:
> I actually already have code for a check (in lilo.c) to insure that the
> files are contiguous and on the first physical disk.  With the lv to pv
> ioctl, that would be easy to extend to any bootable device.

Actually, there is no need for an image to be contiguous, because even
the filesystem does not guarantee a file is contiguous.  The only
requirement is the image be on a single device that the BIOS can see
when it is first booting.

> In implementing this, we need to remember that not just the kernel needs
> to be mapped.  The boot loader any ramdisks need to be known as well.

Yes, once the LVM block mapping works, it will work for all of these.

> What I'd *really* like to see is kernel code for autostarting of LVM
> similar to the autostart of md (side note: 2.4.0-test7 seems to break
> that, though). One step at a time, though.

Yes, it would be nice to eliminate the requirement for an initrd to use
LVM.  It may be that you could put some limits in place to make the root
VG simple enough for the kernel to load.  You could even hard-code it to
have only 1 LV in this VG, which is the root filesystem.  If it was all
__init code for the LVM module, it would not bloat the kernel...  The
tricky part would be to find the right PV for the rootvg before LVM is
loaded...

Cheers, Andreas

Re: [linux-lvm] LVM support for LILO

[Luca Berra]

On Fri, Sep 08, 2000 at 01:50:20PM -0600, Andreas Dilger wrote:
> Yes, it would be nice to eliminate the requirement for an initrd to use
> LVM.  It may be that you could put some limits in place to make the root
> VG simple enough for the kernel to load.  You could even hard-code it to
HP-UX puts info about the boot vg on disk, actually it writes there info
about the posistion of boot, root, swap and dump LVs. These LV are required
to be contiguous, so the info is simple enough.

> have only 1 LV in this VG, which is the root filesystem.  If it was all

uhm, if we want to kill partition tables, we have to cope with the limit
that you cannot put a PV in two different VGs, so this might not work for some
people.

> __init code for the LVM module, it would not bloat the kernel...  The
> tricky part would be to find the right PV for the rootvg before LVM is
> loaded...
would it be simplier if we assume it is the same PV from which we are booting?

L.


-- 
Luca Berra -- bluca@comedia.it
    Communication Media & Services S.r.l.

Re: [linux-lvm] LVM support for LILO

[Christoph Hellwig]

On Fri, Sep 08, 2000 at 01:50:20PM -0600, Andreas Dilger wrote:
> Yes, it would be nice to eliminate the requirement for an initrd to use
> LVM.  It may be that you could put some limits in place to make the root
> VG simple enough for the kernel to load.  You could even hard-code it to
> have only 1 LV in this VG, which is the root filesystem.  If it was all
> __init code for the LVM module, it would not bloat the kernel...  The
> tricky part would be to find the right PV for the rootvg before LVM is
> loaded...

I'm working on this. It is handled very much like md autostart.
In partitions/msdos.c a function is called for every partition with
the lvm id. This function reads the pv structure, and adds it to the
linked list of pvs for this vg (or creates it if this is the first pv).

If all pvs of a vg are found, the vg, lv and pe structures are loaded
from disk and the vg can be activated with a (modified) vgchange -a y.

Expect alpha code in a few weeks.

	Christoph

-- 
Always remember that you are unique.  Just like everyone else.

[linux-lvm] LVM support for LILO

[Andreas Dilger]

Heinz,
Michael Kellen and I have been working to add LILO support for booting
from a LV (i.e. have /boot be an LV, and then not have ANY DOS partitions).

However, the main problem that we are having is that you cannot use
an LV device major/minor to do anything with liblvm.  All of the liblvm
functions use an LV name, it would be good to add an ioctl which takes
a dev_t (e.g. 0x3a01) and returns an LV name, or maybe an lv_t which
we can use with liblvm.  Along the same lines, it may be good to have
an ioctl which takes a dev_t and returns a vg_t of the VG which this LV
is a part of.  Finally, it would be good to take the code out of lvm_map()
which only does block/dev remapping (which lvm_map() will call), but
which also be called by an ioctl like FIBMAP.

How this all fits together is:

1) LILO gets the name of a kernel image (e.g. /boot/vmlinuz) and does stat()
   on it to get the dev_t.

2) LILO does FIBMAP ioctl for each block in the kernel image to find the
   absolute block on the dev_t, and stores this into boot.map.

We need to take the LV dev_t and map it to an lv_t.  Then after LILO does
the FIMBAP on a file block (which returns an LV relative block number),
we need to call a function (ioctl) with (lv_t, lv_block) to return the PV
(dev_t, block), which will then be stored in the boot.map.  LILO needs
the underlying dev_t, because this is translated into a BIOS drive number.

All of these things are relatively easy to do, but it is useless if it
is not in the standard LVM code.  Mapping from a LV dev_t to an lv_t is
simply checking MAJOR(dev) == LVM_MAJOR, return lv[MINOR(dev) + 1] or so.
Doing the block remapping is already in lvm_map(), and just needs to be
moved into a separate function that can be called via ioctl.

Cheers, Andreas

Re: [linux-lvm] LVM support for LILO

[Andi Kleen]

On Thu, Sep 07, 2000 at 12:25:07PM -0600, Andreas Dilger wrote:
> Heinz,
> Michael Kellen and I have been working to add LILO support for booting
> from a LV (i.e. have /boot be an LV, and then not have ANY DOS partitions).

[...]

I did some similar work. I implemented an LVM_BMAP ioctl for LVM that
simply translates a given block to a (dev_t, blocknr in dev). lilo 
simply does a normal FIOBMAP and then calls LVM_BMAP for every block
it gets. When the dev_t ever changes it complains loudly. Then it does
its normal work with the resulting blocks.

It works ok. The only problem is that a standard PV cannot be used for
booting, because it does leave any space for a MBR (it probably needs 
a PV format revision that simply leaves 4K free) 

> However, the main problem that we are having is that you cannot use
> an LV device major/minor to do anything with liblvm.  All of the liblvm
> functions use an LV name, it would be good to add an ioctl which takes
> a dev_t (e.g. 0x3a01) and returns an LV name, or maybe an lv_t which
> we can use with liblvm.  Along the same lines, it may be good to have
> an ioctl which takes a dev_t and returns a vg_t of the VG which this LV
> is a part of.  Finally, it would be good to take the code out of lvm_map()
> which only does block/dev remapping (which lvm_map() will call), but
> which also be called by an ioctl like FIBMAP.

I'm just calling lvm_bmap from my ioctl. It is easy enough (patch against
2.2 appended) 


--- include/linux/lvm.h.LVMBMAP	Wed Aug  2 18:44:26 2000
+++ include/linux/lvm.h	Thu Aug 10 01:29:14 2000
@@ -355,6 +355,10 @@
 
 /* lock the logical volume manager */
 #define	LVM_LOCK_LVM            _IO ( 0xfe, 0x100)
+
+/* bmap, argument lv_bmap_t */
+#define LV_BMAP		_IOWR ( 0xfe, 0x51, 1)
+
 /* END ioctls */
 
 
@@ -534,7 +538,10 @@
    ulong    new_pe;
 } le_remap_req_t;
 
-
+typedef struct lv_bmap {
+    ulong lv_block;
+    dev_t lv_dev;	    
+} lv_bmap_t;
 
 /*
  * Structure Logical Volume (LV) Version 1
--- drivers/block/lvm.c.LVMBMAP	Sun Jul 30 01:55:16 2000
+++ drivers/block/lvm.c	Thu Aug 10 04:53:17 2000
@@ -1076,6 +1076,28 @@
  *
  ********************************************************************/
 
+static int lvm_user_bmap(struct inode *inode, struct lv_bmap *user_result) 
+{ 
+	struct buffer_head bh; 
+	unsigned long block; 
+	int err;
+
+	if (get_user(block, &user_result->lv_block)) 
+		return -EFAULT; 	
+
+	memset(&bh,0,sizeof bh); 
+	bh.b_size = 512; /* XXX */ 
+	bh.b_rsector = block;
+	bh.b_dev = bh.b_rdev = inode->i_dev;
+	if ((err=lvm_map(&bh, READ)) < 0)  {
+		printk("lvm map failed: %d\n", err); 
+		return -EINVAL; 
+	}	
+
+	return put_user(  kdev_t_to_nr(bh.b_rdev), &user_result->lv_dev) ||
+		put_user(bh.b_rsector, &user_result->lv_block) ? -EFAULT : 0;
+} 
+
 /*
  * block device open routine
  */
@@ -1259,6 +1281,10 @@
          vg[VG_BLK(minor)]->lv[LV_BLK(minor)]->lv_status = ( ulong) arg;
          break;
 
+	case LV_BMAP:
+		/* turn logical block into (dev_t, block). non privileged. */ 
+		return lvm_user_bmap(inode, (struct lv_bmap *) arg);  		
+		break; 
 
       /* set allocation flags of a logical volume */
       case LV_SET_ALLOCATION:




-Andi

Re: [linux-lvm] LVM support for LILO

[Andreas Dilger]

Andi Kleen, you write:
> I did some similar work. I implemented an LVM_BMAP ioctl for LVM that
> simply translates a given block to a (dev_t, blocknr in dev). lilo 
> simply does a normal FIOBMAP and then calls LVM_BMAP for every block
> it gets. When the dev_t ever changes it complains loudly. Then it does
> its normal work with the resulting blocks.

Do you have the corresponding patches to LILO?  Have you ever tried
submitting them to the LILO maintainers?

> It works ok. The only problem is that a standard PV cannot be used for
> booting, because it does leave any space for a MBR (it probably needs 
> a PV format revision that simply leaves 4K free) 

I think if you make a partition on your boot disk (even if it is the
full size of the disk), then you will have enough space for a MBR.  No
need to change LVM formats.  You can use full-disk PVs if you want for
your other disks, but it quiets the boot process down a bit if you have
a partition on the disk (or at least it complained the last time I tried
a full-disk PV).

> I'm just calling lvm_bmap from my ioctl. It is easy enough (patch against
> 2.2 appended) 

Ah, you mean lvm_map.  Very clever.  I had thought to take out the mapping
code into another function, but yours is much easier, because you don't
even need to know the LV or do any other complex work.

> +	case LV_BMAP:
> +		/* turn logical block into (dev_t, block). non privileged. */ 
                                                           ^^^^^^^^^^^^^^
This is one area that LVM needs to work on.  Doing the SUSER checks in
liblvm is not really helpful, because you might have disk admin people,
and people can always compile their code without the checks.  Being able
to at least do "pvscan" or "lvdisplay" as an unprivileged user is useful,
and other tasks should be possible if you have write access to /dev/vg/lv
and/or /dev/hdaX.

Cheers, Andreas

Re: [linux-lvm] LVM support for LILO

[Andi Kleen]

On Thu, Sep 07, 2000 at 04:39:39PM -0600, Andreas Dilger wrote:
> Andi Kleen, you write:
> > I did some similar work. I implemented an LVM_BMAP ioctl for LVM that
> > simply translates a given block to a (dev_t, blocknr in dev). lilo 
> > simply does a normal FIOBMAP and then calls LVM_BMAP for every block
> > it gets. When the dev_t ever changes it complains loudly. Then it does
> > its normal work with the resulting blocks.
> 
> Do you have the corresponding patches to LILO?  Have you ever tried
> submitting them to the LILO maintainers?

I hacked lilo, but I never tested them really because I didn't have a spare
HD to experiment with the changed PV format at that time (I noticed the
problem with the PV format only after I did that work :-()  You can have
the untested patches if you want.  From visual inspection the translated
blocks looked ok.

A full solution requires more work, e.g. at least a LV flag so that
LVM can urge the user to rerun lilo after a *move. Support in lilo for LVs
spread over multiple devices would also be nice (I just cheated by requiring
it all on a single device) 


> 
> > It works ok. The only problem is that a standard PV cannot be used for
> > booting, because it does leave any space for a MBR (it probably needs 
> > a PV format revision that simply leaves 4K free) 
> 
> I think if you make a partition on your boot disk (even if it is the
> full size of the disk), then you will have enough space for a MBR.  No
> need to change LVM formats.  You can use full-disk PVs if you want for
> your other disks, but it quiets the boot process down a bit if you have
> a partition on the disk (or at least it complained the last time I tried
> a full-disk PV).

It just does not make much sense then, because with a DOS partition table
you can as well have a partition based /boot


-Andi

Re: [linux-lvm] LVM support for LILO

[Andreas Dilger]

Andi Kleen, you write:
> I hacked lilo, but I never tested them really because I didn't have a spare
> HD to experiment with the changed PV format at that time (I noticed the
> problem with the PV format only after I did that work :-()  You can have
> the untested patches if you want.  From visual inspection the translated
> blocks looked ok.

Yes, please send me a copy...

> A full solution requires more work, e.g. at least a LV flag so that
> LVM can urge the user to rerun lilo after a *move. Support in lilo for LVs
> spread over multiple devices would also be nice (I just cheated by requiring
> it all on a single device) 

Yes, this was discussed a bit in the past, but like all things Linux, it
is better to have something now instead of later.  However, I don't even
know if it would be possible to boot from multiple devices, since I think
this may even be a BIOS thing to load the blocks, otherwise we would never
be restricted to BIOS devices for boot...

> It just does not make much sense then, because with a DOS partition table
> you can as well have a partition based /boot

It's still not good to have a partition-based /boot, because you can't
migrate it, enlarge it, etc (carefully, mind you).  There are still some
limitations for LVM based /boot, but if you have /dev/hda1 that is all
in LVM, you are free to manage it any way you want.  The partition table
is only a few kB...  You can make all your other disks full LVM disks
and save a few more kB, if you are TOTALLY SURE you will never want to
boot from any of them...

Cheers, Andreas

Re: [linux-lvm] LVM support for LILO

[Andi Kleen]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Thu, Sep 07, 2000 at 05:44:03PM -0600, Andreas Dilger wrote:
> Yes, please send me a copy...

Sorry for the delay. I cleaned the patch a bit up and appended it. I also
noticed that I sent you the wrong version of the kernel patch earlier, the
patched lilo needs the ioctl on the character device (the patch I sent adds
it to the block device, because I used that first). I appended a new
kernel patch against 2.2.16 + LVM 0.9 and a patch against lilo 21.5. Again
a warning, the lilo patch is not really tested and may just break.


-Andi


[-- Attachment #2: lilo-21.5-lvm-patch --]
[-- Type: text/plain, Size: 3052 bytes --]

diff -ur lilo-21.5/geometry.c lilo-21.5-work/geometry.c
--- lilo-21.5/geometry.c	Sat Jul 15 22:33:06 2000
+++ lilo-21.5-work/geometry.c	Fri Aug 11 14:02:21 2000
@@ -30,6 +30,18 @@
 #define HDIO_GETGEO HDIO_REQ
 #endif
 
+#define LV_BMAP   _IOWR ( 0xfe, 0x51, 1)
+#ifndef MAJOR
+#define MAJOR(x) (((x) >> 8) & 0xff) 
+#endif
+#define LVM_MAJOR 58
+
+typedef unsigned short kernel_dev_t; 
+
+typedef struct lv_bmap {
+    ulong lv_block;
+    kernel_dev_t lv_dev;           
+} lv_bmap_t;
 
 typedef struct _st_buf {
     struct _st_buf *next;
@@ -40,6 +52,7 @@
 DT_ENTRY *disktab = NULL;
 int old_disktab = 0;
 
+int lvmbmap(dev_t dev, unsigned block, dev_t *curdev);
 
 void geo_init(char *name)
 {
@@ -408,7 +421,9 @@
     DT_ENTRY *walk;
     int inherited,keep_cyls;
 
-    if (MAJOR(device) == MD_MAJOR) {
+    switch (MAJOR(device)) { 
+    case MD_MAJOR:
+    {
         char mdxxx[11];
 	int md_fd, pass;
 	md_array_info_t md_array_info;
@@ -433,7 +448,19 @@
 	    }
 	}
 	close(md_fd);
+	break;	
     }
+    case LVM_MAJOR:
+    {
+	dev_t realdev = 0;	
+	int blk = lvmbmap(device,1,&realdev);
+
+	if (!blk) 
+		pdie("cannot find underlying LVM PV");
+	device = realdev;
+	break;	
+    } 
+    } 
     for (walk = disktab; walk; walk = walk->next)
 	if (walk->device == device) break;
     inherited = !walk && !old_disktab;
@@ -549,6 +576,7 @@
     geo->file = S_ISREG(st.st_mode);
     geo->boot = 1;
     geo->spb = 1;
+    geo->dev = st.st_dev; 
     return geo->fd;
 }
 
@@ -559,6 +587,36 @@
 }
 
 
+int lvmbmap(dev_t dev, unsigned block, dev_t *curdev)
+{
+	static int lvmfd = -1; 
+	lv_bmap_t bm; 
+
+	if (lvmfd < 0) {
+		lvmfd = open("/dev/lvm", O_RDWR); 
+		if (lvmfd < 0) pdie("open of /dev/lvm");
+	}	
+	bm.lv_dev = dev;
+	bm.lv_block = block;
+	
+	if (bm.lv_dev != dev) 
+		pdie("glibc dev_t does not match kernel_dev_t"); 
+ 
+	if (ioctl(lvmfd, LV_BMAP, &bm) < 0) 
+		return 0; 
+	
+	if (!(*curdev)) 
+		*curdev = bm.lv_dev;
+	else if (*curdev != bm.lv_dev) {   
+		/* FIXME: should check if they're really on different
+		   BIOS devices */ 
+		pdie("LVM boot file over multiple PVs"); 
+	}
+
+	return bm.lv_block; 
+}
+
+
 #ifndef FIBMAP
 #define FIBMAP BMAP_IOCTL
 #endif
@@ -576,6 +634,11 @@
     if (geo->file) {
 	if (ioctl(geo->fd,FIBMAP,&block) < 0) pdie("ioctl FIBMAP");
 	if (!block) return 0;
+
+	if (MAJOR(geo->dev) == LVM_MAJOR) { 
+		block = lvmbmap(geo->dev, block, &geo->curdev); 
+		if (!block) return 0; 
+	} 
     }
     sector = block*geo->spb+((offset/SECTOR_SIZE) % geo->spb);
     sector += geo->start;
diff -ur lilo-21.5/geometry.h lilo-21.5-work/geometry.h
--- lilo-21.5/geometry.h	Sat Nov  6 22:09:40 1999
+++ lilo-21.5-work/geometry.h	Thu Aug 10 17:57:37 2000
@@ -16,6 +16,9 @@
     int spb; /* sectors per block */
     int fd,file;
     int boot; /* non-zero after geo_open_boot */
+    dev_t dev; 
+    dev_t curdev;
+    int delayed;
 } GEOMETRY;
 
 typedef struct _dt_entry {
Binary files lilo-21.5/lilo.o and lilo-21.5-work/lilo.o differ
Binary files lilo-21.5/map.o and lilo-21.5-work/map.o differ

[-- Attachment #3: lvm-bmap-4 --]
[-- Type: text/plain, Size: 1607 bytes --]

--- include/linux/lvm.h.LVBMAP	Fri Sep  1 17:40:55 2000
+++ include/linux/lvm.h	Fri Sep  8 13:11:58 2000
@@ -355,6 +355,10 @@
 
 /* lock the logical volume manager */
 #define	LVM_LOCK_LVM            _IO ( 0xfe, 0x100)
+
+/* bmap, argument lv_bmap_t */
+#define LV_BMAP		_IOWR ( 0xfe, 0x51, 1)
+
 /* END ioctls */
 
 
@@ -534,7 +538,10 @@
    ulong    new_pe;
 } le_remap_req_t;
 
-
+typedef struct lv_bmap {
+    ulong lv_block;
+    dev_t lv_dev;	    
+} lv_bmap_t;
 
 /*
  * Structure Logical Volume (LV) Version 1
--- drivers/block/lvm.c.LVBMAP	Mon Aug 28 15:04:34 2000
+++ drivers/block/lvm.c	Fri Sep  8 15:59:53 2000
@@ -1025,6 +1025,10 @@
          }
          return 0;
 
+	case LV_BMAP:
+		/* turn logical block into (dev_t, block). non privileged. */ 
+		return lvm_user_bmap(inode, (struct lv_bmap *) arg);  		
+		break; 
 
       default:
          printk ( KERN_WARNING
@@ -1076,6 +1080,28 @@
  *
  ********************************************************************/
 
+static int lvm_user_bmap(struct inode *inode, struct lv_bmap *user_result) 
+{ 
+	struct buffer_head bh; 
+	unsigned long block; 
+	int err;
+
+	if (get_user(block, &user_result->lv_block)) 
+		return -EFAULT; 	
+
+	memset(&bh,0,sizeof bh); 
+	bh.b_size = 512; /* XXX */ 
+	bh.b_rsector = block;
+	bh.b_dev = bh.b_rdev = inode->i_dev;
+	if ((err=lvm_map(&bh, READ)) < 0)  {
+		printk("lvm map failed: %d\n", err); 
+		return -EINVAL; 
+	}	
+
+	return put_user(  kdev_t_to_nr(bh.b_rdev), &user_result->lv_dev) ||
+		put_user(bh.b_rsector, &user_result->lv_block) ? -EFAULT : 0;
+} 
+
 /*
  * block device open routine
  */

Re: [linux-lvm] LVM support for LILO

[Heinz J. Mauelshagen]

On Thu, Sep 07, 2000 at 11:43:01PM +0200, Andi Kleen wrote:
> On Thu, Sep 07, 2000 at 12:25:07PM -0600, Andreas Dilger wrote:
> > Heinz,
> > Michael Kellen and I have been working to add LILO support for booting
> > from a LV (i.e. have /boot be an LV, and then not have ANY DOS partitions).
> 
> [...]
> 
> I did some similar work. I implemented an LVM_BMAP ioctl for LVM that
> simply translates a given block to a (dev_t, blocknr in dev). lilo 
> simply does a normal FIOBMAP and then calls LVM_BMAP for every block
> it gets. When the dev_t ever changes it complains loudly. Then it does
> its normal work with the resulting blocks.
> 
> It works ok. The only problem is that a standard PV cannot be used for
> booting, because it does leave any space for a MBR (it probably needs 
> a PV format revision that simply leaves 4K free) 

This would be a major change forcing us to move structures around in
existing installations..

There should be no problem with a partition based PV though.

> 
> > However, the main problem that we are having is that you cannot use
> > an LV device major/minor to do anything with liblvm.  All of the liblvm
> > functions use an LV name, it would be good to add an ioctl which takes
> > a dev_t (e.g. 0x3a01) and returns an LV name, or maybe an lv_t which
> > we can use with liblvm.  Along the same lines, it may be good to have
> > an ioctl which takes a dev_t and returns a vg_t of the VG which this LV
> > is a part of.  Finally, it would be good to take the code out of lvm_map()
> > which only does block/dev remapping (which lvm_map() will call), but
> > which also be called by an ioctl like FIBMAP.
> 
> I'm just calling lvm_bmap from my ioctl. It is easy enough (patch against
> 2.2 appended) 
> 

Thanks for providing the code Andi.

We can start from that but i like to extract the bare mapping code from
lvm_map() and call that one from bmap to have a cleaner interface.

> 
> --- include/linux/lvm.h.LVMBMAP	Wed Aug  2 18:44:26 2000
> +++ include/linux/lvm.h	Thu Aug 10 01:29:14 2000
> @@ -355,6 +355,10 @@
>  
>  /* lock the logical volume manager */
>  #define	LVM_LOCK_LVM            _IO ( 0xfe, 0x100)
> +
> +/* bmap, argument lv_bmap_t */
> +#define LV_BMAP		_IOWR ( 0xfe, 0x51, 1)
> +
>  /* END ioctls */
>  
>  
> @@ -534,7 +538,10 @@
>     ulong    new_pe;
>  } le_remap_req_t;
>  
> -
> +typedef struct lv_bmap {
> +    ulong lv_block;
> +    dev_t lv_dev;	    
> +} lv_bmap_t;
>  
>  /*
>   * Structure Logical Volume (LV) Version 1
> --- drivers/block/lvm.c.LVMBMAP	Sun Jul 30 01:55:16 2000
> +++ drivers/block/lvm.c	Thu Aug 10 04:53:17 2000
> @@ -1076,6 +1076,28 @@
>   *
>   ********************************************************************/
>  
> +static int lvm_user_bmap(struct inode *inode, struct lv_bmap *user_result) 
> +{ 
> +	struct buffer_head bh; 
> +	unsigned long block; 
> +	int err;
> +
> +	if (get_user(block, &user_result->lv_block)) 
> +		return -EFAULT; 	
> +
> +	memset(&bh,0,sizeof bh); 
> +	bh.b_size = 512; /* XXX */ 
> +	bh.b_rsector = block;
> +	bh.b_dev = bh.b_rdev = inode->i_dev;
> +	if ((err=lvm_map(&bh, READ)) < 0)  {
> +		printk("lvm map failed: %d\n", err); 
> +		return -EINVAL; 
> +	}	
> +
> +	return put_user(  kdev_t_to_nr(bh.b_rdev), &user_result->lv_dev) ||
> +		put_user(bh.b_rsector, &user_result->lv_block) ? -EFAULT : 0;
> +} 
> +
>  /*
>   * block device open routine
>   */
> @@ -1259,6 +1281,10 @@
>           vg[VG_BLK(minor)]->lv[LV_BLK(minor)]->lv_status = ( ulong) arg;
>           break;
>  
> +	case LV_BMAP:
> +		/* turn logical block into (dev_t, block). non privileged. */ 
> +		return lvm_user_bmap(inode, (struct lv_bmap *) arg);  		
> +		break; 
>  
>        /* set allocation flags of a logical volume */
>        case LV_SET_ALLOCATION:
> 
> 
> 
> 
> -Andi

-- 

Regards,
Heinz      -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Bartningstr. 12
                                                  64289 Darmstadt
                                                  Germany
Mauelshagen@Sistina.com                           +49 6151 7103 86
                                                       FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM support for LILO

[Andi Kleen]

On Fri, Sep 08, 2000 at 12:11:09AM +0000, Heinz J. Mauelshagen wrote:
> On Thu, Sep 07, 2000 at 11:43:01PM +0200, Andi Kleen wrote:
> > On Thu, Sep 07, 2000 at 12:25:07PM -0600, Andreas Dilger wrote:
> > > Heinz,
> > > Michael Kellen and I have been working to add LILO support for booting
> > > from a LV (i.e. have /boot be an LV, and then not have ANY DOS partitions).
> > 
> > [...]
> > 
> > I did some similar work. I implemented an LVM_BMAP ioctl for LVM that
> > simply translates a given block to a (dev_t, blocknr in dev). lilo 
> > simply does a normal FIOBMAP and then calls LVM_BMAP for every block
> > it gets. When the dev_t ever changes it complains loudly. Then it does
> > its normal work with the resulting blocks.
> > 
> > It works ok. The only problem is that a standard PV cannot be used for
> > booting, because it does leave any space for a MBR (it probably needs 
                        ^^^^
                        doesn't of course
> > a PV format revision that simply leaves 4K free) 
> 
> This would be a major change forcing us to move structures around in
> existing installations..

Yes. It may be at least possible to do it compatible though
(let it check for the new PV on the new position or fall back to the old) 

It is probably reasonable to require a backup/restore to boot from LVM
(people who don't want it probably already have other means to boot the
system and can continue to use the old format)

> 
> There should be no problem with a partition based PV though.

With a partition based PV you can as well create /boot in a DOS
partition.


-Andi

Re: [linux-lvm] LVM support for LILO

[Andi Kleen]

On Fri, Sep 08, 2000 at 12:11:09AM +0000, Heinz J. Mauelshagen wrote:
> We can start from that but i like to extract the bare mapping code from
> lvm_map() and call that one from bmap to have a cleaner interface.

It'll just lead to code duplication. You probably do not want to add
another function call into the mapping path, so it would need to be inlined
anyways, causing at least two copies of the code. Probably not a big deal
as such, but many small bloat additions add up in the log run.


-Andi

Re: [linux-lvm] LVM support for LILO

[Heinz J. Mauelshagen]

On Thu, Sep 07, 2000 at 12:25:07PM -0600, Andreas Dilger wrote:
> Heinz,
> Michael Kellen and I have been working to add LILO support for booting
> from a LV (i.e. have /boot be an LV, and then not have ANY DOS partitions).

THX, that's good news :-{)

> 
> However, the main problem that we are having is that you cannot use
> an LV device major/minor to do anything with liblvm.  All of the liblvm
> functions use an LV name, it would be good to add an ioctl which takes
> a dev_t (e.g. 0x3a01) and returns an LV name, or maybe an lv_t which
> we can use with liblvm.

Actually you can achieve this by

	int l = int lv_get_index_by_kdev_t(vg_t * vg, kdev_t dev);

after reading the VG structure hierarchy pointed too by "vg" with

	int lvm_tab_vg_read_with_pv_and_lv(char * vg_name, vg_t ** vg);



After this you can access the lv_t structure of the LV by

	vg->lv[l]

and the LV name by

	vg->lv[l]->lv_name


> Along the same lines, it may be good to have
> an ioctl which takes a dev_t and returns a vg_t of the VG which this LV
> is a part of.

Please use

	int vg_status_with_pv_and_lv(char * vg_name, vg_t ** vg);

by inserting the VG name using the index you got like in the
lv_get_index_by_kdev_t() example

	vg_status_with_pv_and_lv(vg->lv[l]->vg_name, vg_t ** vg);


> Finally, it would be good to take the code out of lvm_map()
> which only does block/dev remapping (which lvm_map() will call), but
> which also be called by an ioctl like FIBMAP.

Yes, i can do that.

> 
> How this all fits together is:
> 
> 1) LILO gets the name of a kernel image (e.g. /boot/vmlinuz) and does stat()
>    on it to get the dev_t.
> 
> 2) LILO does FIBMAP ioctl for each block in the kernel image to find the
>    absolute block on the dev_t, and stores this into boot.map.

O.k.

> 
> We need to take the LV dev_t and map it to an lv_t.  Then after LILO does
> the FIMBAP on a file block (which returns an LV relative block number),
> we need to call a function (ioctl) with (lv_t, lv_block) to return the PV
> (dev_t, block), which will then be stored in the boot.map.  LILO needs
> the underlying dev_t, because this is translated into a BIOS drive number.
> 
> All of these things are relatively easy to do, but it is useless if it
> is not in the standard LVM code.  Mapping from a LV dev_t to an lv_t is
> simply checking MAJOR(dev) == LVM_MAJOR, return lv[MINOR(dev) + 1] or so.
> Doing the block remapping is already in lvm_map(), and just needs to be
> moved into a separate function that can be called via ioctl.
> 


So if i got you right and the use of the above mentioned library functions
serves your needs, the only change to the existing LVM software would be
in the driver to support an ioctl which returns a dev_t and block on a
PV given the LV dev_t and the relative block number.

I'ld recommend LV_MAP_LVA2PVA (Logical Volume MAP Logical Volume Address
to Physical Volume Address).


Question: how do you want to ensure that all kernel image blocks really
          are BIOS addressable? They could for eg. live on a MD or could be out
          of the BIOS addressable range of blocks.

-- 

Regards,
Heinz      -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Bartningstr. 12
                                                  64289 Darmstadt
                                                  Germany
Mauelshagen@Sistina.com                           +49 6151 7103 86
                                                       FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM support for LILO

[Andreas Dilger]

Heinz J. Mauelshagen, you write:
> > Michael Kellen and I have been working to add LILO support for booting
> > from a LV (i.e. have /boot be an LV, and then not have ANY DOS partitions).
> 
> THX, that's good news :-{)

Please see instead Andi Kleen's way of doing this (posted today).  It is
much simpler.  Can you add his patch to 0.9?

> 	int l = int lv_get_index_by_kdev_t(vg_t * vg, kdev_t dev);

This will only work if you already have the vg_t.  If you only know dev, it
is not possible to find which VG is is a part of without doing crazy things.

> Please use  int vg_status_with_pv_and_lv(char * vg_name, vg_t ** vg);

Again, it only works if you know something about the VG in advance.  I
think these functions may be useful even if we don't need them for LILO,
and they only take a few lines in the kernel...

> So if i got you right and the use of the above mentioned library functions
> serves your needs, the only change to the existing LVM software would be
> in the driver to support an ioctl which returns a dev_t and block on a
> PV given the LV dev_t and the relative block number.

Andi Kleen's patch to make a fake buffer_head, and just call lvm_map() is
even easier.

> Question: how do you want to ensure that all kernel image blocks really
>           are BIOS addressable? They could for eg. live on a MD or could
>           be out of the BIOS addressable range of blocks.

LILO already handles many of these issues, or at least warns about them.
None of them are specific to LVM, so people are aware of them already
(although LVM may hide a few of the details).  It would be documented
that the /boot LV can reside only on 1 disk, and that it must reside on
a BIOS addressible disk.  Most systems create /boot on the first disk
when they are installed, and even with the number of kernels on my system
it is only a few MB (1 or 2 PEs is enough).

LILO only supports RAID1 MD devices, so the kernel will only have blocks
on 1 device in the end, or LILO will fail.  This is easily verified by
checking that dev is the same for all of the LV mapped blocks.

Cheers, Andreas

Re: [linux-lvm] LVM support for LILO

[Heinz J. Mauelshagen]

On Thu, Sep 07, 2000 at 05:29:17PM -0600, Andreas Dilger wrote:
> Heinz J. Mauelshagen, you write:
> > > Michael Kellen and I have been working to add LILO support for booting
> > > from a LV (i.e. have /boot be an LV, and then not have ANY DOS partitions).
> > 
> > THX, that's good news :-{)
> 
> Please see instead Andi Kleen's way of doing this (posted today).  It is
> much simpler.  Can you add his patch to 0.9?

Basically the approach i already started looks similar.

But it takes into account having a clean separation of the pure mapping
code _and_ the error checking/snapshot code which lives in lvm_map()
as well.

> 
> > 	int l = int lv_get_index_by_kdev_t(vg_t * vg, kdev_t dev);
> 
> This will only work if you already have the vg_t.  If you only know dev, it
> is not possible to find which VG is is a part of without doing crazy things.

Please have a look at how lvscan.c does a similar job.

> 
> > Please use  int vg_status_with_pv_and_lv(char * vg_name, vg_t ** vg);
> 
> Again, it only works if you know something about the VG in advance.  I
> think these functions may be useful even if we don't need them for LILO,
> and they only take a few lines in the kernel...

Not a big deal.

char IOCTL could be LV_STATUS_BYDEV_T.


> 
> > So if i got you right and the use of the above mentioned library functions
> > serves your needs, the only change to the existing LVM software would be
> > in the driver to support an ioctl which returns a dev_t and block on a
> > PV given the LV dev_t and the relative block number.
> 
> Andi Kleen's patch to make a fake buffer_head, and just call lvm_map() is
> even easier.

Yes.
The above solution is easy as well and cleaner.

> 
> > Question: how do you want to ensure that all kernel image blocks really
> >           are BIOS addressable? They could for eg. live on a MD or could
> >           be out of the BIOS addressable range of blocks.
> 
> LILO already handles many of these issues, or at least warns about them.
> None of them are specific to LVM, so people are aware of them already
> (although LVM may hide a few of the details).  It would be documented
> that the /boot LV can reside only on 1 disk, and that it must reside on
> a BIOS addressible disk.  Most systems create /boot on the first disk
> when they are installed, and even with the number of kernels on my system
> it is only a few MB (1 or 2 PEs is enough).

O.k.

We would need at least an additional "allocation on a single device" or
"don't pvmove" status flag for the LV to ensure that no wrong pvmove(8)
can happen.

> 
> LILO only supports RAID1 MD devices, so the kernel will only have blocks
> on 1 device in the end, or LILO will fail.  This is easily verified by
> checking that dev is the same for all of the LV mapped blocks.

Yep.

-- 

Regards,
Heinz      -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Bartningstr. 12
                                                  64289 Darmstadt
                                                  Germany
Mauelshagen@Sistina.com                           +49 6151 7103 86
                                                       FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM support for LILO

[Luca Berra]

On Fri, Sep 08, 2000 at 01:02:35PM +0000, Heinz J. Mauelshagen wrote:
> > LILO already handles many of these issues, or at least warns about them.
> > None of them are specific to LVM, so people are aware of them already
> > (although LVM may hide a few of the details).  It would be documented
> > that the /boot LV can reside only on 1 disk, and that it must reside on
> > a BIOS addressible disk.  Most systems create /boot on the first disk
> > when they are installed, and even with the number of kernels on my system
> > it is only a few MB (1 or 2 PEs is enough).

beware that bios addressable might mean below cylinder 1024 if your bios
doesn't handle lba32

> We would need at least an additional "allocation on a single device" or
contigous should imply this, but then  more than just this

> "don't pvmove" status flag for the LV to ensure that no wrong pvmove(8)
> can happen.
i'd like to be able to pvmove even the boot lv (i.e. i am migrating
to a larger disk)

L.

-- 
Luca Berra -- bluca@comedia.it
    Communication Media & Services S.r.l.

Re: [linux-lvm] LVM support for LILO

[Heinz J. Mauelshagen]

On Fri, Sep 08, 2000 at 03:47:06PM +0200, Luca Berra wrote:
> On Fri, Sep 08, 2000 at 01:02:35PM +0000, Heinz J. Mauelshagen wrote:
> > > LILO already handles many of these issues, or at least warns about them.
> > > None of them are specific to LVM, so people are aware of them already
> > > (although LVM may hide a few of the details).  It would be documented
> > > that the /boot LV can reside only on 1 disk, and that it must reside on
> > > a BIOS addressible disk.  Most systems create /boot on the first disk
> > > when they are installed, and even with the number of kernels on my system
> > > it is only a few MB (1 or 2 PEs is enough).
> 
> beware that bios addressable might mean below cylinder 1024 if your bios
> doesn't handle lba32

Damn it.

> 
> > We would need at least an additional "allocation on a single device" or
> contigous should imply this, but then  more than just this
> 
> > "don't pvmove" status flag for the LV to ensure that no wrong pvmove(8)
> > can happen.
> i'd like to be able to pvmove even the boot lv (i.e. i am migrating
> to a larger disk)

Sure.
The attribute would be resetable anyway to allow this.


-- 

Regards,
Heinz      -- The LVM guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Bartningstr. 12
                                                  64289 Darmstadt
                                                  Germany
Mauelshagen@Sistina.com                           +49 6151 7103 86
                                                       FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] LVM support for LILO

[Michael J Kellen]

On Thu, Sep 07, 2000 at 05:29:17PM -0600,
in response to Heinz J. Mauelshagen's question:
>> Question: how do you want to ensure that all kernel image blocks really
>>           are BIOS addressable? They could for eg. live on a MD or could
>>           be out of the BIOS addressable range of blocks.

Andreas Dilger wrote:
> LILO already handles many of these issues, or at least warns about them.
> None of them are specific to LVM, so people are aware of them already
> (although LVM may hide a few of the details).  It would be documented
> that the /boot LV can reside only on 1 disk, and that it must reside on
> a BIOS addressible disk.  Most systems create /boot on the first disk
> when they are installed, and even with the number of kernels on my system
> it is only a few MB (1 or 2 PEs is enough).

I actually already have code for a check (in lilo.c) to insure that the
files are contiguous and on the first physical disk.  With the lv to pv
ioctl, that would be easy to extend to any bootable device.

In implementing this, we need to remember that not just the kernel needs
to be mapped.  The boot loader (boot.b -- side note: get LILO 21.1.5 if
you don't have it and give boot-menu.b a whirl) and any ramdisks need to
be known as well.

What I'd *really* like to see is kernel code for autostarting of LVM
similar to the autostart of md (side note: 2.4.0-test7 seems to break
that, though). One step at a time, though.

Lastly, remember that if you install LILO in the MBR, you don't need to
restructure the PV.

MIchael Kellen

Re: [linux-lvm] LVM support for LILO

[Ralph Jennings]

On Fri, Sep 08, 2000 at 09:03:15AM -0500, Michael J Kellen wrote:
[snip]
> What I'd *really* like to see is kernel code for autostarting of LVM
> similar to the autostart of md (side note: 2.4.0-test7 seems to break
> that, though). One step at a time, though.

Is this being worked on?  Also putting the LVM stuff on the end of the
disk (as MD does) would be nice too.

> Lastly, remember that if you install LILO in the MBR, you don't need to
> restructure the PV.

What if the PV is the entire hda?  As in:
    1. md0 is the entire hda, and hdc
    2. pv_raid is the entire md0
    3. lv_root, lv_usr, lv_swap, etc is under pv_raid

 -Ralph