lkml.org 
[lkml]   [2005]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1b/7] dlm: core locking
From
Date
On Thu, 2005-04-28 at 05:33, Lars Marowsky-Bree wrote:
> On 2005-04-27T22:26:38, David Teigland <teigland@redhat.com> wrote:
<snip>
>
> > > And, I assume that the delivery of a "node down" membership event
> > > implies that said node also has been fenced.
> > Typically it does if you're combining the dlm with something that requires
> > fencing (like a file system). Fencing isn't relevant to the dlm itself,
> > though, since the dlm software isn't touching any storage.
>
> Ack. Good point, I was thinking too much in terms of GFS/OCFS2 here ;-)
>

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?

Is there a existing DLM that does not depend on fencing? (you said
yours was modeled after the VMS DLM, didn't they depend on fencing?)

How would an application use a DLM that does not depend on fencing?

Thanks,

Daniel





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-28 18:44    [W:0.065 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site