Orphan lock requirements for using OpenDLM with OpenGFS

Hi all,

Yesterday, I updated OpenGFS' DESIGN-opendlm doc to attempt to describe
requirements (as I understand them at the moment) for the use of OpenDLM
orphan locks in support of OpenGFS journal recovery.  I'd be grateful
for comments and suggestions.

The two biggest gaps seem to be:

1)  The ability to grab a lock that's being "held" as an orphan.
OpenGFS needs to be able to grab just a few special locks (e.g. journal
lock) on resources that may be locked as orphans held by a dead node.
We need to ignore the orphans, *but not* ignore other locks that may be
non-orphans.  There seems to be no API way of doing that (looking at the
programmers guide) ... Do we need a new "LKM_IGNOREORPHANS" flag or
similar?

2)  After journal recovery, we need to purge all those orphans ...  But,
only those for the filesystem that was just recovered (there can be
multiple OGFS filesystems mounted in the cluster).  All kernel-space
OpenDLM clients use the same "pid" of 0xF7F7F7F7.  A call to purge would
blow away *all* locks belonging to (kernel space clients on) the dead
node, not just the ones for the recovered filesystem ...

2) (cont'd)  ... To differentiate filesystems/lockspaces, we've created
a 32-bit hash of a unique string.  The hash value becomes part of the
lockname.  Could we use this 32-bit hash somehow as a cluster-wide
client identifier, so purge would clean out only this client's locks?


One other question ... For user-space clients, how does a pid identify a
given client *beyond the scope of a single node*, i.e. across the
cluster?  Can a client on one node ask to purge locks from a client on
another node?  How does it know which pid to purge?

-- Ben --

Opinions (and questions) are mine, not Intel's


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click