RE: Re: [Opendlm-devel] Orphan lock requirements for using OpenDLM with OpenGFS

>=20
> There is another big gap :
>=20
> The current orphan lock mechanism is only valid for lock client failed
> case. In node fail case, all locks (including orphan locks)=20
> held by this
> node will be cleaned. I've poped this issue to this list in previous
> mail. (please check the attachment for more detailed information)
>=20
> Best Regards,
> Stan
>=20

Thanks for bringing this up again ... I failed to grasp it earlier.
This does seem like a big gap, and I'm wondering if it can be reliably
bridged at all??

Consider a dead node that is the directory/master/only-lock-requestor
(i.e. *everything*) for a given resource.  No other node would know
about that resource, and therefore the cluster would not be able to
retain any knowledge about that resource.  Such locks would simply
disappear, orphanable or not.  (Sanity check ... Is this true??).

Maybe this is why OPenDLM doesn't bother to try to retain orphans on
dead nodes; it can't guarantee that *all* would be retained??

In that case, I don't think there is any way to guarantee OpenGFS the
kind of persistent protection it needs, in order to keep other nodes
from writing over on-disk resources that the dead node was writing.  The
protection must persist until after the dead node's journal is recovered
by a surviving node. =20

Memexp has this capability, but it looks like OpenDLM doesn't, and
wouldn't without a lot of work (e.g. make sure that more than one node
retains current copies of resource and lock info ... Doesn't sound easy
to do reliably ... Sanity check ... is this true??).

Arghh.

-- Ben --

Opinions 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