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

More questions ... See below.  I'm going to be away from the project for
a few days, wanted to get these out to the list.  Thanks.

-- Ben --

Opinions are mine, not Intel's

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf=20
> Of Zickus II, Don
> Sent: Thursday, April 08, 2004 3:10 PM
> To: [email protected]
> Subject: RE: [ogfs-dev]Re: [Opendlm-devel] Orphan lock=20
> requirements for using OpenDLM with OpenGFS
>=20
>=20
> Hello Ben,
>=20
> After talking to people here, I realized our database is=20
> involved in a similar situation.  Our solution seems to be a=20
> combination of the classic deadman locks and the=20
> DLM_VALNOTVALID return code. =20

Do all of your locks use LVBs?  Even shared (e.g. CR) locks?

> In either of these situations,=20
> we set a flag internally stating the database is possibly=20
> corrupt, hold off on any new lock requests, re-validate all=20
> the journal logs and correct any half written data.   Once=20
> the database is stable again, allow lock requests to proceed.=20
>  In the scenario you proposed below, our deadman locks would=20
> go off via an AST and all locking requests would be halted.

Is there any guarantee of order of processing the deadman locks vs.
other locks?  I'm guessing that there's not, and that's why you use the
LVB feature in addition.
 =20
> Any locks that manage to get through that check, should be=20
> caught at another check once they receive the lock.

Could anything (e.g. a non-LVB-using lock) sneak through before any
deadman or LVB locks alert you that something may be wrong?

Once OpenDLM knows that a node is dead, does it stop processing any lock
requests until after it has cleaned up from the dead node?

Even if it does ...

I'm just wondering if, for example, a shared, non-LVB lock request that
had been blocked by the dead node could be granted (during cleanup
processing) before the requesting node knew that anything was wrong.  In
that case, the requesting node might be able to read and use corrupt
data that had been protected by an EX lock on the dead node.

 =20
> I am not sure how the OpenGFS is implemented but how do you=20
> deal with this on a single node cluster without OpenDLM?  I=20
> assume OpenGFS has internal lock mechanisms to prevent=20
> multiple processes from writing to disk at the same time. =20
> And if one of those processes crashes, how does OpenGFS recover? =20
>=20
> Best Regards,
> Don
>=20
>=20
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf=20
> Of Cahill, Ben M
> Sent: Thursday, April 08, 2004 2:29 PM
> To: [email protected];=20
> [email protected]
> Subject: RE: [ogfs-dev]Re: [Opendlm-devel] Orphan lock=20
> requirements for using OpenDLM with OpenGFS
>=20
>=20
> >=20
> > There is another big gap :
> >=20
> > The current orphan lock mechanism is only valid for lock=20
> client failed=20
> > case. In node fail case, all locks (including orphan locks) held by=20
> > this node will be cleaned. I've poped this issue to this list in=20
> > previous mail. (please check the attachment for more detailed=20
> > information)
> >=20
> > Best Regards,
> > Stan
> >=20
>=20
> Thanks for bringing this up again ... I failed to grasp it=20
> earlier. This does seem like a big gap, and I'm wondering if=20
> it can be reliably bridged at all??
>=20
> Consider a dead node that is the directory/master/only-lock-requestor
> (i.e. *everything*) for a given resource.  No other node=20
> would know about that resource, and therefore the cluster=20
> would not be able to retain any knowledge about that=20
> resource.  Such locks would simply disappear, orphanable or=20
> not.  (Sanity check ... Is this true??).
>=20
> Maybe this is why OPenDLM doesn't bother to try to retain=20
> orphans on dead nodes; it can't guarantee that *all* would be=20
> retained??
>=20
> In that case, I don't think there is any way to guarantee=20
> OpenGFS the kind of persistent protection it needs, in order=20
> to keep other nodes from writing over on-disk resources that=20
> the dead node was writing.  The protection must persist until=20
> after the dead node's journal is recovered by a surviving node. =20
>=20
> Memexp has this capability, but it looks like OpenDLM=20
> doesn't, and wouldn't without a lot of work (e.g. make sure=20
> that more than one node retains current copies of resource=20
> and lock info ... Doesn't sound easy to do reliably ...=20
> Sanity check ... is this true??).
>=20
> Arghh.
>=20
> -- Ben --
>=20
> Opinions are mine, not Intel's
>=20



-------------------------------------------------------
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