Messages in this thread | | | Date | Wed, 27 Apr 2005 22:26:38 +0800 | From | David Teigland <> | Subject | Re: [PATCH 1b/7] dlm: core locking |
| |
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
- 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/
| |