From: "Heinz J. Mauelshagen" <Mauelshagen@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Root on LVM and vgscan
Date: Mon, 28 May 2001 11:20:30 +0000 [thread overview]
Message-ID: <20010528112030.H26710@sistina.com> (raw)
In-Reply-To: <200105250828.JAA11414@queeg.britain.agilent.com>; from dick@britain.agilent.com on Fri, May 25, 2001 at 09:28:34AM +0100
On Fri, May 25, 2001 at 09:28:34AM +0100, Dick Middleton wrote:
> I have root running on lvm on sw raid partitions on linux 2.2.18. It all
> works fine. However I have had difficulty during booting after adding new
> LVs. The symptom is that the initial mounts of LVs fails or the wrong
> partition is mounted.
>
> What happens is that vgscan is run during the initrd phase and so the lvmtab
> is updated on the ram disk. Once the root file system on the hard disk has
> been mounted the lvmtab on that comes into use. That has not been updated by
> vgscan and so does not reflect the changes.
>
> Obviously it's possible to run vgscan again (between remounting root rw and
> checking the other discs) to update the lvmtab but it does beg a few
> questions.
Yes, that's the option (forcing some overhead).
The other would be to get the actual /etc/lvmtab* from the initial ram disk :-)
>
> 1) why does mount use the data in lvmtab and not in /proc to find out about
> active VGs?
mount doesn't access /etc/lvmtab* at all.
The problem is that minor numbers are not striktly related to logical volumes;
they are associated at vgscan time.
>
> 2) if lvmtab is so essetial why is it not updated by vgcreate/lvcreate and
> other utilities when changes are made?
See above.
>
> 3) would it not be possible/better to update lvmtab from /proc without doing
> a rescan.
That could only be partially done, because /etc/lvmtab* contains the complete
metadata whereas /proc doesn't.
>
> I don't know the issues involved and reasoning behind the design of this
> aspect of LVM but it does seem to me that there is something less than ideal
> in the current scheme.
The virtuall assignement of minor numbers to LVs causes the problem in the
root on LVM (and NFS) case. That'l likly be changed anyway.
>
> Dick
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2001-05-28 11:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-25 8:28 [linux-lvm] Root on LVM and vgscan Dick Middleton
2001-05-28 11:20 ` Heinz J. Mauelshagen [this message]
2001-05-28 12:44 ` Dick Middleton
2001-05-28 16:14 ` Heinz J. Mauelshagen
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=20010528112030.H26710@sistina.com \
--to=mauelshagen@sistina.com \
--cc=linux-lvm@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.