[Linux-cluster] Some GDLM questions

[Jeff]

These are from reviewing http://people.redhat.com/~teigland/sca.pdf
and the CVS copy of cluster/dlm/doc/libdlm.txt.
------------------------------------------------------------------

If a program requests a lock on the AST side can it wait for
the lock to complete without returning from the original AST
routine?  Would it use the poll/select mechanism to do this?

What's the best way to implement a blocking lock request in
an application where some requests are synchronous and some
are asynchronous? Use semop() after the lock request and in 
the lock completion routine? Is semop() safe to call from
a thread on Linux? Would pthread_cond_wait()/pthread_cond_signal()
be better?

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)

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?

GDLM is not listed as a client of FENCE. This seems to imply
that a GDLM application has to interact directly with FENCE to 
deal with the unknown state problem in a 2 node cluster where each 
member has 1 vote and expected votes is 1 (section 3.2.6.2, page 28)
as otherwise the same lockspace could end up existing on multiple
machines in a single cluster. How would an application interact
with FENCE to prevent this or does this have to be handled by
configuring the cluster to reboot in this case?

libdlm.txt has a vague comment which reads:
   One further point about lockspace operations is that there is no locking
   on the creating/destruction of lockspaces in the library so it is up to
   the application to only call dlm_*_lockspace when it is sure that
   no other locking operations are likely to be happening.
Does this mean 'no other locking operations' by the process which is
creating the lockspace? no other requests to create a lock space on
that cluster member? in the cluster as a whole?


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.

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?

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.