Re: [PATCH 1b/7] dlm: core locking

From: David Teigland
Date: Wed Apr 27 2005 - 09:27:47 EST

On Wed, Apr 27, 2005 at 03:41:42PM +0200, Lars Marowsky-Bree wrote:

> So in effect, the delivery of the suspend/membership distribution/resume
> events are three cluster-wide barriers?
> I can see how that simplifies the recovery algorithm.

Correct. I actually consider it two external barriers: the first after
the lockspace has been suspended, the second after lockspace recovery is

> 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.

> So we can't deliver it raw membership events. Noted.

That's right, it requires more intelligence on the part of the external
management system in userspace.

> If you want to think about this in terms of locking hierarchy, it's the
> high-level feature rich sophisticated aka bloated lock manager which
> controls the "lower level" faster and more scalable "sublockspace" and
> coordinates it in terms of the other complex objects (like fencing,
> applications, filesystems etc).
> Just some food for thought how this all fits together rather neatly.

Interesting, and sounds correct. I must admit that using the word "lock"
to describe these CRM-level inter-dependent objects is new to me.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at