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

David Teigland
2005-04-27T14:24:10Z

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

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

Dave