From: Andreas Dilger <adilger@turbolabs.com>
To: Linux LVM mailing list <linux-lvm@msede.com>
Subject: Re: [linux-lvm] SuSE/LVM boot problem
Date: Wed, 3 May 2000 17:50:57 -0600 (MDT) [thread overview]
Message-ID: <200005032350.e43NowH30788@webber.adilger.net> (raw)
Eric M. Hopper writes:
> One idea for making this happens is to have a way of locking
> logical extents to physical extents so that you have to use a special
> command to unlock them. This kind of thing is already done in different
> parts of LVM to make sure you don't delete logical volumes that are in
> use, or remove physical volumes that still have extents allocated to
> them.
> One this exists, altering lilo to detect LVM, and automatically
> lock the necessary logical->physical extent mappings isn't too hard.
> Well, the problem is that moving a few physical extents does not
> obviously suggest re-running lilo. Many physical extents are fine to
> move, and trying to keep track of which physical extents lilo cares
> about, and which one's it doesn't isn't a task I think a sysadmin should
> have to deal with.
I agree. If it is possible/easy to already do this, I would say do it.
I'm also saying that if it isn't possible (or if it is, but it's a lot
of work), then it isn't really a show stopper. People don't often move
their kernels around, and if they do, there is no indication that LILO
should be run either. The /boot filesystem (or / if no /boot) is special
in other ways as well, and I don't think many sysadmins will have a problem
with remembering not to move it.
> While I expected that /boot would have to be ext2fs, and
> allocated a very generous 50M to it, I purposely compiled lvm into the
> kernel in the hopes of one day having an lvm / parition. Of course,
> resizing an lvm / partition is a dicey affair. :-)
Why do you say that? You can resize it while it is mounted:
http://ext2resize.sourceforge.net/
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
next reply other threads:[~2000-05-03 23:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-03 23:50 Andreas Dilger [this message]
2000-05-04 2:28 ` [linux-lvm] SuSE/LVM boot problem dgould
2000-05-04 5:21 ` Michael Loftis
2000-05-04 2:38 ` Eric M. Hopper
-- strict thread matches above, loose matches on Subject: below --
2000-05-04 12:18 Shaw, Marco
2000-05-03 18:09 Andreas Dilger
2000-05-03 21:01 ` Eric M. Hopper
2000-05-03 7:38 Michael Marxmeier
2000-05-03 16:53 ` dgould
2000-05-31 9:01 ` Andi Kleen
2000-05-31 16:13 ` Christoph Hellwig
2000-05-31 16:18 ` Andi Kleen
2000-05-31 18:25 ` Michael Marxmeier
2000-06-01 12:15 ` Ulf Bartelt
2000-06-01 9:01 ` David Gould
2000-05-02 5:20 Marco Shaw
2020-11-27 16:17 ` Michael Marxmeier
2000-05-02 18:41 ` dgould
2000-05-02 21:22 ` Jan Niehusmann
2000-05-02 22:18 ` Heinz Mauelshagen
2000-05-03 10:05 ` Ulf Bartelt
2000-05-31 8:40 ` Andi Kleen
2000-05-03 0:15 ` Marco Shaw
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=200005032350.e43NowH30788@webber.adilger.net \
--to=adilger@turbolabs.com \
--cc=linux-lvm@msede.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).