From: Jesse Sipprell <jss@evcom.net>
To: Andreas Dilger <adilger@turbolinux.com>
Cc: Paul Jakma <paulj@itg.ie>, Jos Visser <josv@osp.nl>, linux-lvm@msede.com
Subject: Re: [linux-lvm] LVM in shared parallel SCSI environment
Date: Tue, 14 Nov 2000 17:03:05 -0500 [thread overview]
Message-ID: <20001114170305.A27524@kevorkian.evcom.net> (raw)
In-Reply-To: <200011142115.eAELFHV11698@webber.adilger.net>; from adilger@turbolinux.com on Tue, Nov 14, 2000 at 02:15:16PM -0700
On Tue, Nov 14, 2000 at 02:15:16PM -0700, Andreas Dilger wrote:
> Jesse Sipprell writes:
> > Actually, it's entirely possible to run a non-shared-media-aware filesystem as
> > long as no more than one cluster node has a given file system mounted at a
> > time.
> >
> > To illustrate:
> >
> > |-------- VG --------|
> > ||====== LV0 =======||
> > || (ext2) || --> Mounted on Cluster Node 1
> > ||==================||
> > ||====== LV1 =======||
> > || (ext2) || --> Mounted on Cluster Node 2
> > ||==================||
> > ||====== LV2 =======||
> > || (ext2) || --> Mounted on Cluster Node 3
> > ||==================||
> > ||====== LV3 =======||
> > || (ext2) || --> Mounted on Cluster Node 4
> > ||==================||
> > | |
> > | Free Space in VG |
> > | |
> > |====================|
>
> Far safer to simply have a separate VG for each node, and import it on the
> backup node when you do a failover. Since you have to have some sort of
> external control for the filesystems, doing the import at the same time is
> not any more overhead.
Safer, certainly, but won't this make extending/reducing an LV problematic?
For example, say that in 6 months from now it becomes necessary to move 100MB
of capacity from LV0 to LV1; now per your assumption that LV0 and LV1 on are
on separate VGs, one can only extend and/or reduce the involved VGs by this
amount if the increment/decrement size is a multiple of the PV sizes.
> > One can use the benefits of LVM to unmount LV0's fs on Cluster Node 1, resize
> > the LV, resize the fs and remount. Now, Cluster Node's 2, 3 and 4 need to
> > have their in-core LVM metadata updated in order to see the new size of LV0.
> > Once this is done via the vgchange bounce, everything is consistant.
>
> Yes, except when someone also does a resize on another filesystem before
> they have synced up the VG, you have corrupt filesystems and LVM. You've
> made something that looks to be "highly available" into something that
> facilitates destroying your important data. In many critical systems, it
> is very rare that you would be able to take filesystems 2, 3, 4 offline
> in order to sync the LVM back up.
Absolutely. This is the reasoning behind my original question regarding
"refreshing" the in-core LVM metadata on cluster nodes. LVM is still a win
without clustering features, however the potential exists for exactly what you
described (and other horrors). The only solution (until LVM-clustering comes
to fruition), in my organization, is to procedurally make sure that only one
person is in charge of a cluster, resizing LVs, filesystems, etc, as well as
to make sure that person is fully aware of the dangers involved with current
LVM in a shared media environment.
> PS - no need to unmount the ext2 filesystem to do the resize with the
> right tools.
Certainly. ;)
--
Jesse Sipprell
Technical Operations Director
Evolution Communications, Inc.
800.496.4736
* Finger jss@evcom.net for my PGP Public Key *
next prev parent reply other threads:[~2000-11-14 22:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-11 13:46 [linux-lvm] LVM in shared parallel SCSI environment Jesse Sipprell
2000-11-14 6:44 ` Jos Visser
2000-11-14 14:38 ` Jesse Sipprell
2000-11-14 16:09 ` Paul Jakma
2000-11-14 19:29 ` Jesse Sipprell
[not found] ` <200011142115.eAELFHV11698@webber.adilger.net>
2000-11-14 22:03 ` Jesse Sipprell [this message]
2000-11-14 22:40 ` Andreas Dilger
2000-11-15 7:04 ` Jos Visser
2000-11-21 13:44 ` Matthew O'Keefe
2000-11-21 18:01 ` John DeFranco
2000-11-21 22:25 ` Jos Visser
2000-11-22 0:42 ` Matthew O'Keefe
2000-11-22 11:40 ` 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=20001114170305.A27524@kevorkian.evcom.net \
--to=jss@evcom.net \
--cc=adilger@turbolinux.com \
--cc=josv@osp.nl \
--cc=linux-lvm@msede.com \
--cc=paulj@itg.ie \
/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