From: Daniel Phillips <phillips@istop.com>
To: Lars Marowsky-Bree <lmb@suse.de>
Cc: Daniel McNeil <daniel@osdl.org>,
David Teigland <teigland@redhat.com>,
Steven Dake <sdake@mvista.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 1b/7] dlm: core locking
Date: Fri, 29 Apr 2005 04:25:24 -0400 [thread overview]
Message-ID: <200504290425.24485.phillips@istop.com> (raw)
In-Reply-To: <20050428164529.GF21645@marowsky-bree.de>
On Thursday 28 April 2005 12:45, Lars Marowsky-Bree wrote:
> On 2005-04-28T09:39:22, Daniel McNeil <daniel@osdl.org> wrote:
> > Since a DLM is a distributed lock manager, its usage is entirely for
> > locking some shared resource (might not be storage, might be shared
> > state, shared data, etc). If the DLM can grant a lock, but not
> > guarantee that other nodes (including the ones that have been kicked
> > out of the cluster membership) do not have a conflicting DLM lock, then
> > any applications that depend on the DLM for protection/coordination
> > be in trouble. Doesn't the GFS code depend on the DLM not being
> > recovered until after fencing of dead nodes?
>
> It makes a whole lot of sense to combine a DLM with (appropriate)
> fencing so that the shared resources are protected. I understood David's
> comment to rather imply that fencing is assumed to happen outside the
> DLM's world in a different component; ie more of a comment on sane
> modularization instead of sane real-world configuration.
But just because fencing is supposed to happen in an external component,
we can't wave our hands at it and skip the analysis. We _must_ identify the
fencing assumptions and trace the fencing paths with respect to every
recovery algorithm in every cluster component, including the dlm.
I suspect that when we do get around to properly scrutinizing fencing
requirements of specific recovery algorithms, we will find that the fencing
system currently on offer for gfs needs a little work.
Regards,
Daniel
next prev parent reply other threads:[~2005-04-29 8:25 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-25 16:58 [PATCH 1b/7] dlm: core locking David Teigland
2005-04-25 18:34 ` Nikita Danilov
2005-04-25 20:44 ` Daniel Phillips
2005-04-25 22:27 ` Nikita Danilov
2005-04-26 1:34 ` Daniel Phillips
2005-04-25 20:41 ` Jesper Juhl
2005-04-26 5:00 ` Daniel Phillips
2005-04-25 21:54 ` Steven Dake
2005-04-26 5:49 ` David Teigland
2005-04-26 17:40 ` Steven Dake
2005-04-26 22:24 ` Daniel Phillips
2005-04-26 23:04 ` Steven Dake
2005-04-27 0:53 ` Daniel Phillips
2005-04-27 1:50 ` Steven Dake
2005-04-27 4:21 ` Daniel Phillips
2005-04-27 3:02 ` David Teigland
2005-04-27 13:41 ` Lars Marowsky-Bree
2005-04-27 14:26 ` David Teigland
2005-04-28 12:33 ` Lars Marowsky-Bree
2005-04-28 16:39 ` Daniel McNeil
2005-04-28 16:45 ` Lars Marowsky-Bree
2005-04-29 8:25 ` Daniel Phillips [this message]
2005-05-02 20:45 ` Lars Marowsky-Bree
2005-05-02 23:23 ` Daniel Phillips
2005-04-29 4:01 ` David Teigland
2005-04-29 22:58 ` Daniel McNeil
2005-04-30 4:29 ` David Teigland
2005-04-30 9:09 ` Daniel Phillips
2005-04-30 10:32 ` Lars Marowsky-Bree
2005-04-30 11:12 ` Daniel Phillips
2005-05-02 20:51 ` Lars Marowsky-Bree
2005-05-02 22:21 ` Daniel Phillips
2005-05-05 12:25 ` Stephen C. Tweedie
2005-05-05 12:40 ` copy_to_user question linux
2005-05-05 13:13 ` Richard B. Johnson
2005-05-05 19:29 ` [PATCH 1b/7] dlm: core locking Daniel Phillips
2005-04-28 2:52 ` Daniel Phillips
2005-04-28 12:37 ` Lars Marowsky-Bree
2005-04-28 23:43 ` Daniel Phillips
2005-04-28 6:49 ` Daniel Phillips
2005-04-28 12:55 ` Lars Marowsky-Bree
2005-04-29 0:26 ` Daniel Phillips
2005-04-29 2:52 ` David Teigland
2005-04-29 3:49 ` Daniel Phillips
2005-05-02 21:00 ` Lars Marowsky-Bree
2005-05-03 2:54 ` David Teigland
2005-04-27 12:33 ` Domen Puncer
2005-04-27 13:30 ` David Teigland
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=200504290425.24485.phillips@istop.com \
--to=phillips@istop.com \
--cc=akpm@osdl.org \
--cc=daniel@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@suse.de \
--cc=sdake@mvista.com \
--cc=teigland@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox