From: David Teigland <teigland@redhat.com>
To: Daniel McNeil <daniel@osdl.org>
Cc: Lars Marowsky-Bree <lmb@suse.de>, 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: Sat, 30 Apr 2005 12:29:15 +0800 [thread overview]
Message-ID: <20050430042915.GA10473@redhat.com> (raw)
In-Reply-To: <1114815509.18352.200.camel@ibm-c.pdx.osdl.net>
On Fri, Apr 29, 2005 at 03:58:29PM -0700, Daniel McNeil wrote:
> So the Connection Manager controlled membership, quorum, and fencing
> (stalling all disk i/o, etc). AFAIR, the DLM would get a membership
> event and do recovery after quorum and fencing.
Right
> From the description above, nodes not part of the membership with quorum
> could not do anything.
Right
> I have always thought that an distributed application could use the DLM
> alone to protect access to shared storage. The DLM would coordinate
> access between the distributed application running on the nodes
> in the cluster AND DLM locks would not be recovered and possibly
> granted to applications running on the nodes still in the membership
> until after nodes that are no longer a member of the cluster are safely
> prevented from doing any harm.
>
> So, when I said that the DLM was dependent on fencing, I was thinking
> of the membership, quorum, prevention of harm (stalling of i/o to
> prevent corrupting shared resource) as described above.
>
> So, if an application was using your DLM to protect shared storage,
> I think you are saying it possible the DLM lock could be granted
> before the node that was previously holding the lock and now is not
> part of the cluster is fenced. Is that right?
It depends on how the clustering infrastructure coordinates the various
aspects of recovery. The dlm doesn't specify how that's done because
there's no universal answer. If it's important to your application that
fencing happens before the dlm grants locks from failed nodes, then you
need to be sure that's how the infrastructure coordinates recovery of
fencing, the dlm and your application.
I can talk about GFS's requirements on how fencing and dlm recovery
happen, but other apps will be different.
GFS requires that a gfs fs has been "suspended" (told that recovery will
be happening) on all nodes _before_ the dlm grants locks from failed nodes
(i.e. before the dlm starts recovery). Because the dlm grants locks
previously held by failed nodes when its recovery completes, gfs has a
much stricter standard for using dlm locks while it's in this suspended
state: the gfs recovery process can acquire new locks, but no one else.
That leaves GFS's fencing requirement. GFS requires that a failed node be
fenced prior to gfs being told to begin recovery for that node (which
involves recovering the journal of the failed node.)
So for gfs, it's important that fencing and dlm recovery both happen
before gfs recovery, but the order of fencing and dlm recovery (with
respect to each other) doesn't matter. As I said, the dlm doesn't require
that fencing happen first, but as you suggest, an application may want it
that way.
> PS if an application is writing to local storage, what does it need a
> DLM for?
My experience is pretty limited, but I suspect there are distributed
applications, requiring synchronization, that don't write to shared
storage.
Thanks for the info and good questions
Dave
next prev parent reply other threads:[~2005-04-30 4:26 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
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 [this message]
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=20050430042915.GA10473@redhat.com \
--to=teigland@redhat.com \
--cc=akpm@osdl.org \
--cc=daniel@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lmb@suse.de \
--cc=sdake@mvista.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