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

=20
> >=20
> > > 2. We can't invalidate LVB any more.
> >=20
> > Re: #2, that's been troubling me also, although I don't think we use
> > that feature for OGFS, do we?
>=20
> There is a method called "lvb_unhold" in G-LOCK, I'm not sure=20
> if LKM_INVVALBLK=20
> is need by it.=20

I don't think so ... It just means that OGFS (on this node) is done
using the LVB, but there's no need to invalidate the LVB.  It should be
readable by other nodes, assuming that this or some other node keeps a
lock on the resource (so the LVB can stay "alive").

There's some calls in memexp's memexp_unhold_lvb() to "clear_lvb()",
which sounds almost like it's invalidating the LVB. However, it's only
clearing a bit in the memexp lock record, saying which nodes have an
interest in the lock's LVB.  Memexp will invalidate (really, just forget
about) the LVB when no node holds the LVB's lock.  OpenDLM behaves
pretty much the same way, so we don't need to explicitly invalidate the
LVB (anyhow, the lock module doesn't know if other nodes hold locks, so
it can't know when to invalidate the LVB vs. not invalidate it).


> > How about a DLM_RECOVER status bit that would get set=20
> whenever a lock
> > was granted as part of the ODLM lock recovery process?? =20
> That would be
> > conclusive, and would not restrict the use of the LVB.  I=20
> think it would
> > be pretty easy to implement ... Just look at some recovery=20
> global state
> > machine variables when granting the lock, and set the status flag
> > appropriately.
>=20
> It looks like good idea. I think it wouldn't impact ODLM's original=20
> function/sematic. If it is acceptable to all others? Any concern?

I think CA objected, reasonably so, since it affects the API ... See
other mail from Don.



I've been a little distracted today ... I still want to audit/understand
what would happen if:

1) *this* node requests a lock, blocked by another node, *just before*
that other node dies, and
2) prior to this request, dying node was the
master/directory/only-requestor (that is, the only node that knew
anything about the resource).

Will *this* node grant the lock request as part of this node's lock
recovery process??  Would it have DLM_VALNOTVALID status?

Another way of looking at it, assuming that all locks used LVBs:  Would
each and every lock granted during the lock recovery process have
DLM_VALNOTVALID status?  If not, then I think a lock could "sneak by",
which could cause problems ...

... With 30 years of experience of using the DLM_VALNOTVALID approach of
recovery detection, my guess is that the window of opportunity for
"sneaking by" is very small, if it exists at all.

-- Ben --

Opinions are mine, not Intel's


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click