Messages in this thread | | | Subject | Re: [PATCH 1b/7] dlm: core locking | From | Daniel McNeil <> | Date | Thu, 28 Apr 2005 09:39:22 -0700 |
| |
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/
| |