[Linux-cluster] Some GDLM questions

[David Teigland]

> Does conversion deadlock occur only when a conversion is
> about to be queued and its granted/requested state is 
> incompatible with another lock already on the conversion queue?
> (eg. there is a PR->EX conversion queued and another PR->EX
> conversion is about to be queued)

Yes.  The application can't know ahead of time, of course, whether this will
happen since both PR holders may convert to EX at the same time.


> Other DLMs do not deliver a blocking AST to a lock which is not
> on the granted queue. This means that a lock which queued for
> conversion will not get a blocking AST if it is interfering with
> another lock being added to the conversion queue. Does GDLM do this 
> as well or are blocking ASTs delivered to all locks regardless of 
> their state?

We only send blocking asts for locks on the granted queue.  This may
be a change from what was written in the sca document (which has become
incorrect in some places over the past 6 months.)


> Possible Enhancements:
> ----------------------
> The following two items are areas where GDLM appears to differ from
> the DLMs from HP and IBM (eg for VMS, Tru64, AIX and OpenDLM for
> Linux which is derived from IBM's DLM for AIX). These differences 
> aren't incompatible with GFS's requirements and could be implemented 
> as optional behaviors. I'd be happy to work on patches for
> these if they would be welcome.

Yes, we'd be very happy to get patches.


> GDLM is described as granting new lock requests as long as they 
> are compatible with the existing lock mode regardless of the 
> existence of a conversion queue. The other DLMs mentioned above
> always queue new lock requests if there are any locks on the conversion 
> queue. Certain mechanisms can't be implemented without this kind of
> ordering. Would it be possible to make the alternate behavior a property 
> of the lock space or a property of a grant request so it can be 
> utilized where necessary?

If that's the more standard behavior we should look at making it default
for us, too.  Otherwise a new flag sounds appropriate.


> Certain tasks are simplified if the return status of a lock indicates
> whether it was granted immediately or ended up on the waiting queue.
> Other DLMs which have both synchronous and asynchronous completion
> mechanisms implement this via a flag which requests synchronous
> completion if the lock is available, otherwise the request is queued
> and the asynchronous mechanism is used. This is particularly useful 
> for deadman locks that control recovery to distinguish between 
> the first instance of a service to start and recovery conditions.
> There are other (more complex) techniques to implement this but 
> even though GDLM is purely an asynchronous mechanism, it still would 
> be possible for the completion status to indicate (if requested) 
> whether the lock was granted immediately or not.

A "flags" field in the LKSB can also be used to return information like this.

-- 
Dave Teigland  <teigland at redhat.com>