Linux LVM users
 help / color / mirror / Atom feed
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 *

  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