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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
next prev parent 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).