From: Andreas Dilger <adilger@turbolinux.com>
To: Jan Niehusmann <jan@gondor.com>
Cc: Andreas Dilger <adilger@turbolinux.com>, linux-lvm@msede.com
Subject: Re: [linux-lvm] Exporting VG
Date: Tue, 31 Oct 2000 14:05:33 -0700 (MST) [thread overview]
Message-ID: <200010312105.e9VL5XY11520@webber.adilger.net> (raw)
In-Reply-To: <20001031203559.A8120@gondor.com> "from Jan Niehusmann at Oct 31, 2000 08:35:59 pm"
Jan writes:
> > When you do vgexport, this does not do anything like NFS export (does NOT
> > allow network access to the VG). It allows you to physically move the
> > disks to another machine.
>
> Is vgexport/vgimport doing something important? I just moved a harddisk with
> a vg to another computer without vgexport/vgimport and didnot notice any
> problems. Or is it only needed if I add a vg to an already running system?
I think the only thing that vgexport does is mark on disk that the VG
is "exported" and not shown on vgscan or imported when a "vgchange -a"
is done. On AIX, there is no difference on disk for imported and exported
VGs, the VG state is stored in a config file.
IMHO, we should not store this state in the VG, nor advocate running
"vgscan" on each boot. From what I have read in the past on this mailing
list, running vgscan on boot is likely to delete important info from
/etc/lvmtab if there is a minor problem, that has to later be restored
(if possible).
It would be a lot safer to keep the state of LVM in /etc/lvmtab, and
only add or remove VGs with administrator actions (explicit vgimport,
vgexport, vgscan (for a new system or major problems). This at least
lets you know at boot time that a VG has a problem, rather than vgscan
simply deleting it from lvmtab.
What will make this a lot more likely is the work that Heinz is doing
on PVIDs, so that you only store the VGID + vgname in /etc/lvmtab
and then only the PVIDs in the VGDA. You don't have to worry about
device names changing if disks are added/moved/removed, because you
never depend on the device name.
PVIDs will also make vgimport much easier (like AIX) so you only specify
a single device and the VGDA knows all of the PVIDs that belong to that
volume group. Using VG names is dangerous if you are moving VGs between
systems in case the two systems have identical VG names.
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 prev parent reply other threads:[~2000-10-31 21:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-31 17:42 [linux-lvm] Exporting VG Xavi Fustero
2000-10-31 18:16 ` Andreas Dilger
2000-10-31 19:35 ` Jan Niehusmann
2000-10-31 21:05 ` Andreas Dilger [this message]
2000-11-01 1:34 ` Heinz J. Mauelshagen
2000-11-01 2:25 ` Eric M. Hopper
2000-11-01 6:20 ` Andreas Dilger
-- strict thread matches above, loose matches on Subject: below --
2000-11-02 10:34 Xavi Fustero
2000-11-02 12:15 ` Eric M. Hopper
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=200010312105.e9VL5XY11520@webber.adilger.net \
--to=adilger@turbolinux.com \
--cc=jan@gondor.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 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.