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

Stanley Wang <[email protected]> Tue, 27 Apr 2004 23:34:57 +0800 (CST)
Newsgroups gmane.comp.file-systems.opengfs.devel
Message-ID <[email protected]>
On Mon, 26 Apr 2004, Cahill, Ben M wrote:


> > 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.
> 
> Can you confirm statement #1?  If it's true, then I don't understand how
> CA can use DLM_VALNOTVALID as a recovery indicator.
Sorry. It's my fault, I just read codes in valueblock(). And in 
alloc_resource(), I find all new resource are marked as RSRC_VALID. I also write 
a little test case to confirm that. Sorry again for my careless.

> 
> > 2. We can't invalidate LVB any more.
> 
> Re: #2, that's been troubling me also, although I don't think we use
> that feature for OGFS, do we?

There is a method called "lvb_unhold" in G-LOCK, I'm not sure if LKM_INVVALBLK 
is need by it. 

> 
> In any case, it seems to me that use of the DLM_VALNOTVALID is kind of
> "work-aroundish".  That is, it's a somewhat indirect indication that the
> lock recovery is happening, and subject to some uncertainty, and/or LVB
> usage restrictions (i.e. can't use LKM_INVVALBLK) and requirements (i.e.
> must use an LVB for every lock).
> 
> How about a DLM_RECOVER status bit that would get set whenever a lock
> was granted as part of the ODLM lock recovery process??  That would be
> conclusive, and would not restrict the use of the LVB.  I think it would
> be pretty easy to implement ... Just look at some recovery global state
> machine variables when granting the lock, and set the status flag
> appropriately.

It looks like good idea. I think it wouldn't impact ODLM's original 
function/sematic. If it is acceptable to all others? Any concern?

> 
> > 
> > And since deadman lock will be granted before all new lock requests 
> > (issued after node down event),  I think use  deadman lock as the 
> > notification is early enough.
> 
> But that doesn't keep any of the locks that were blocked by the dead
> node from being granted to other nodes, during the lock recovery
> process.  There could be many locks waiting, requested before the node
> down event, to be granted!  Allowing grants on these could allow other
> nodes to write to areas that they shouldn't (i.e. the areas that the
> dead node was writing).  That's the whole purpose of the (fake)
> persistence of the dead node's EX locks.

You are right. If we can make sure that deadman lock are granted before all the 
other locks, we can also block following granted lock. To achieve this, we can 
add attributes to deadman lock LKM_RECOVER_FISRT, but it's bad hack, I think 
your previous suggestion (DLM_RECOVER) is better :)

Best Regards,
Stan

-- 
Opinions expressed are those of the author and do not represent Intel
Corporation




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