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

Please see my comments below.

[snip]

>CA uses the DLM_VALNOTVALID invalid LVB status as a possible earlier
>indicator.  I haven't convinced myself that that is early enough, or
>conclusive enough (discussion was in the attachment, "false
>positive/negative"), to serve as the trigger for withholding locks from
>OGFS (but it might be, and I might not understand it well enough!).
>Plus, it forces us to use LVBs with every lock (maybe not a huge
>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).
>
>  
>
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.
2. We can't invalid LVB any more.

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. And we needn't care about orphan lock any 
more.

Any comments?

>>After the node who 
>>replays journal
>>completes its work, it notifies (though a dedicate "recover_complete" 
>>lock?) all
>>the others that the blocked requests can continue now. And 
>>then the OGFS 
>>cluster
>>resumes.
>>    
>>
>
>Yes, "recover_complete" locks might work.  The good thing about this is
>that each lock would be filesystem-specific (a concern if the user
>mounts multiple OGFS filesystems).  I think that each lock would need to
>be node- or journal-specific as well (multiple nodes might need to
>recover multiple journals before continuing operation).  I'd rather use
>locks than the callbacks, etc., ... I'll keep working on this.
>  
>
I only want to use "recovery_complete" lock as a broadcast channel, only 
it's AST is usful. And it should be FS specific, one for each OGFS instance.
And in order to mount multi OGFS on one node, we need change the fact 
that all ODLM's kernel clients shares one pid/cid. It should not be a 
problem, we could resolve it later.

Best Regards,
Stan

-- 
Opinions expressed are those of the author and do not represent Intel
Corporation
"gpg --recv-keys --keyserver wwwkeys.pgp.net E1390A7F"
{E1390A7F:3AD1 1B0C 2019 E183 0CFF  55E8 369A 8B75 E139 0A7F}



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