RE: RE: [Opendlm-devel] ODLM/OGFS Recovery

Comments below.

>=20
> >=20
> > >CA uses the DLM_VALNOTVALID invalid LVB status as a=20
> possible earlier=20
> > >indicator.  I haven't convinced myself that that is early=20
> enough, or=20
> > >conclusive enough (discussion was in the attachment, "false=20
> > >positive/negative"), to serve as the trigger for withholding
> > locks from
> > >OGFS (but it might be, and I might not understand it well=20
> enough!).=20
> > >Plus, it forces us to use LVBs with every lock (maybe not a huge=20
> > >problem, but nice to avoid if possible).  And, it prevents
> > us from using
> > >the LKM_INVVALBLK flag!  (but I don't think there's a need
> > to, so not a
> > >problem).
> > >
> > > =20
> > >
> > Using DLM_VALNOTVALID will cause much trouble for us.
> > 1. When you try to lock a new resource with (lock_mode < PW +
> > LKM_VALBLK), you will get DLM_VALNOTVALID.
>=20
> Can you confirm statement #1?  If it's true, then I don't=20
> understand how CA can use DLM_VALNOTVALID as a recovery indicator.
>=20

I am going to disagree with that statement.  We use NL locks all the =
time (as place holders), and this problem is never seen.  What is =
supposed to happen is during a purge process (when a client, a resource, =
or a node disappears), the resource is invalidated if a purging lock had =
mode >=3D PW.  Now normally the lock is downgraded to NL (internally by =
OpenDLM) before being purged to prevent the invalidation.  But if for =
some reason it can not (ie a node dies), then the invalidation happens.  =
Now during the recovery process a new master is selected for the =
resource with the invalid bit set.  This bit will cause the =
DLM_VALNOTVALID code to be returned to the next granted lock (regardless =
of lock_mode I believe).  If the scenario happens such that a =
'surviving' node has a granted lock >=3DPW (before the recovery process) =
then you should NOT see the DLM_VALNOTVALID bit set and everything =
should function normally.  In this case you wait for the deadman locks =
to trigger to signal the client a node has disappeared. =20


> > 2. We can't invalidate LVB any more.
>=20
> Re: #2, that's been troubling me also, although I don't think=20
> we use that feature for OGFS, do we?
>=20
> In any case, it seems to me that use of the DLM_VALNOTVALID=20
> is kind of "work-aroundish".  That is, it's a somewhat=20
> indirect indication that the lock recovery is happening, and=20
> subject to some uncertainty, and/or LVB usage restrictions=20
> (i.e. can't use LKM_INVVALBLK) and requirements (i.e. must=20
> use an LVB for every lock).
>=20

The VMS design and implementation has been around for ~30 years, I doubt =
the DLM_VALNOTVALID code is work-aroundish. :)  In fact our application =
has been using VMS clustering and the DLM_VALNOTVALID methodology for =
roughly the same time frame without any issues.  And senior DB engineers =
here say using the LVB for every lock is common in the industry.  Not =
that I am disagreeing with you, I am trying to point out that this =
methodology seems to work and should be given the benefit of the doubt =
and we would have to frown upon any changes in this area (especially =
since this would cause our client code to have to be recompiled during a =
time of a code freeze over here). ;)=20

> How about a DLM_RECOVER status bit that would get set=20
> whenever a lock was granted as part of the ODLM lock recovery=20
> process??  That would be conclusive, and would not restrict=20
> the use of the LVB.  I think it would be pretty easy to=20
> implement ... Just look at some recovery global state machine=20
> variables when granting the lock, and set the status flag=20
> appropriately.
>=20
>=20
> >=20
> > And since deadman lock will be granted before all new lock requests
> > (issued after node down event),  I think use  deadman lock as the=20
> > notification is early enough.
>=20
> But that doesn't keep any of the locks that were blocked by=20
> the dead node from being granted to other nodes, during the=20
> lock recovery process.  There could be many locks waiting,=20
> requested before the node down event, to be granted! =20
> Allowing grants on these could allow other nodes to write to=20
> areas that they shouldn't (i.e. the areas that the dead node=20
> was writing).  That's the whole purpose of the (fake)=20
> persistence of the dead node's EX locks.
>=20

That's not necessarily true.  If you use the LVB in combination with =
DLM_VALNOTVALID return code, you should be fine. =20

> > And we needn't care about
> > orphan lock any=20
> > more.
>=20
> Agreed.  Orphan locks are not going to help OGFS.

Thank you.  I was getting nervous admist all the ideas you had for =
orphan locks.  Not that we would have protested (as we don't use them) =
but orphan locks touch a lot of code internally. =20

Regards,
Don

>=20
> -- Ben --
>=20
> Opinions are mine, not Intel's
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at=20
> ThinkGeek For a limited time only, get FREE Ground shipping=20
> on all orders of $35 or more. Hurry up and shop folks, this=20
> offer expires April 30th!=20
> http://www.thinkgeek.com/freeshipping/?cpg=12297
>=20
> _______________________________________________
> Opendlm-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opendlm-devel
>=20
>=20


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297