All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ragnar Kjørstad" <lvm@ragnark.vestdata.no>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Cluster LVM
Date: Wed Feb 27 12:14:02 2002	[thread overview]
Message-ID: <20020227191419.J27155@vestdata.no> (raw)
In-Reply-To: <20020227101949.M12832@lynx.adilger.int>; from adilger@turbolabs.com on Wed, Feb 27, 2002 at 10:19:49AM -0700

On Wed, Feb 27, 2002 at 10:19:49AM -0700, Andreas Dilger wrote:
> On Feb 27, 2002  12:45 +0100, Remco Post wrote:
> > clusters all have one major problem to solve: split brain. Make sure that the 
> > node manipulating the LV/VG does indeed have the right to do so, and doesn't 
> > screw up everything for everybody. Maybe introduce a (LV/VG) master concept 
> > into the VG, so as long as that is set, no other node in the cluster will 
> > manipulate anything in the vg. (just some random rant, ignore if I'm talking 
> > nonsense ;)
> 
> Having a single master is a _terrible_ idea, since this would mean that
> if that node is down you are unable to change the VG until/if it is back
> working again.

The VG being locked is not _that_ terrible - after all - you only need
this to change your storage configuration (I don't expet the LVM to
actually lock access to the device).

> Rather use a DLM (as the other poster suggested) and a client needs to
> get a lock on the VG in order to change anything.  You can start with
> a lock per VG and one per shared PV not in a VG, and then go more fine
> grained if you want (e.g. write lock on VG and specific LV being changed,
> which does not block users of other LVs).  In the end, because you are
> not changing a VG configuration very often, and it doesn't take very long
> when you do (excluding pvmove), the big lock is probably enough.

Alternatively one could implement the cluster LVM as a simple
"resource", and leave it to the resource manager to do locking and
STONITH. The ocf (Open Cluster Framework) or "linux-ha" lists would be
good places to query for more information.



-- 
Ragnar Kjørstad
Big Storage

  reply	other threads:[~2002-02-27 12:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-27  5:21 [linux-lvm] Cluster LVM Gitansh Chadha
2002-02-27  5:33 ` Jeff Layton
2002-02-27  5:45   ` Remco Post
2002-02-27 11:19     ` Andreas Dilger
2002-02-27 12:14       ` Ragnar Kjørstad [this message]
2002-02-28  4:24         ` Remco Post
2002-02-28  4:59           ` Prashant Kharche
2002-02-28  5:31             ` Joe Thornber
2002-02-28  7:03               ` Prashant Kharche
2002-02-28  8:32                 ` Joe Thornber
2002-02-28  9:08                   ` Prashant Kharche
2002-02-28  9:43                     ` Remco Post
2002-02-28 12:01                     ` Joe Thornber
2002-02-28  4:17       ` Remco Post
2002-02-27  8:34 ` tim
  -- strict thread matches above, loose matches on Subject: below --
2007-10-16 14:20 [linux-lvm] cluster LVM Jordi Prats
2007-10-17  8:19 ` Patrick Caulfield
2007-10-17  8:22   ` Bryn M. Reeves
2001-03-14 15:22 [linux-lvm] Cluster LVM Jos Visser
2001-03-14 17:10 ` Heinz J. Mauelshagen
2001-03-14 17:07   ` Jeffrey B Layton

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=20020227191419.J27155@vestdata.no \
    --to=lvm@ragnark.vestdata.no \
    --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.