linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Heinz J. Mauelshagen <Heinz.Mauelshagen@t-online.de>
To: Andreas Dilger <adilger@turbolinux.com>
Cc: mge@sistina.com, linux-lvm@msede.com
Subject: Re: [linux-lvm] LVM support for LILO
Date: Fri, 8 Sep 2000 13:02:35 +0000	[thread overview]
Message-ID: <20000908130235.C25034@srv.t-online.de> (raw)
In-Reply-To: <200009072329.RAA21600@lynx.turbolabs.com>; from adilger@turbolinux.com on Thu, Sep 07, 2000 at 05:29:17PM -0600

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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  reply	other threads:[~2000-09-08 13:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-07 18:25 [linux-lvm] LVM support for LILO Andreas Dilger
2000-09-07 21:43 ` Andi Kleen
2000-09-07 22:39   ` Andreas Dilger
2000-09-07 22:46     ` Andi Kleen
2000-09-07 23:44       ` Andreas Dilger
2000-09-08 14:25         ` Andi Kleen
2000-09-08  0:11   ` Heinz J. Mauelshagen
2000-09-07 22:14     ` Andi Kleen
2000-09-07 23:00     ` Andi Kleen
2000-09-08  0:02 ` Heinz J. Mauelshagen
2000-09-07 23:29   ` Andreas Dilger
2000-09-08 13:02     ` Heinz J. Mauelshagen [this message]
2000-09-08 13:47       ` Luca Berra
2000-09-08 19:09         ` Heinz J. Mauelshagen
2000-09-08 14:03     ` Michael J Kellen
2001-02-27  0:30       ` Ralph Jennings
  -- strict thread matches above, loose matches on Subject: below --
2000-09-08 19:39 Andreas Dilger
2000-09-08 19:50 Andreas Dilger
2000-09-09  7:44 ` Luca Berra
2000-09-09 10:07 ` Christoph Hellwig

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=20000908130235.C25034@srv.t-online.de \
    --to=heinz.mauelshagen@t-online.de \
    --cc=Mauelshagen@sistina.com \
    --cc=adilger@turbolinux.com \
    --cc=linux-lvm@msede.com \
    --cc=mge@sistina.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).