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

Thanks for comments ... That's a helpful sanity check ... See below.

> -----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.  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. =20
> Any locks that manage to get through that check, should be=20
> caught at another check once they receive the lock.

Yes, there could be a number of lock requests queued up within OpenDLM
that would be "instantly" granted once a node dies, so the receive-end
check is necessary.
 =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.

Yes, the g_lock layer handles locking for processes within a given node,
and passes lock requests to the cluster when needed (it can't grant a
lock to a process until it gets a lock from the cluster), via a plug-in
lock module (e.g. memexp or opendlm).  For single-node operation, g_lock
can use the "nolock" lock module, which trivially fakes inter-node lock
management functionality.
 =20
> And if one of those processes crashes, how does OpenGFS recover?=20

I don't remember seeing such a mechanism, but I should take another
look.  It's been a while.  ;-)  This would be within the g_lock layer.

-- Ben --=20

Opinions are mine, not Intel's

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