Subject: [nfsv4] Getting out of edge condition hell

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 24 Jun 2006 18:37:18 -0400

I'm doing the spec changes for RECLAIM_COMPLETE and this has meant that
I have had to also do changes on the section about edge conditions and
the logic to deal with them.
 
One thing that I have discovered is that there is no discussion of when
the bit that says that locks have been revoked can be reset.  Clearly,
the fact that there has been lock expiration or administrative lock
revocation should not mean that a client should be unable to reclaim
locks forever.  
 
Despite the lack of explicit discussion, it appears valid to reset this
bit when a client gets a new (i.e. non-reclaim) lock after a reboot, but
only if there is a general understanding that the client, by doing a
normal locking request terminated his reclaim requests and acknowledged
that any locks not reclaimed at that point where lost.  I know that Mike
argued strongly for this position and I found his arguments convincing,
but there remained controversy about this and I don't think we ever
reached consensus on this. I think this will remain an issue for
RFC3530bis.
 
With regard to v4.1, with RECLAIM_COMPLETE, we have a clearer situation.
There, RECLAIM_COMPLETE will provide the semantics we need to allow us
to turn off the bit and make the client able to reclaim locks
subsequently.
 
But this raises another issue about allowing a client out of the
edge-condition state, without having one cycle in which he can't reclaim
locks.  Suppose a client loses a lock do to administrative revocation.
If the server immediately reboots, before the client finds out about the
revocation, then it is justified/essential not to let him reclaim locks.
But suppose a lease period goes by and he find out the revocation.  Once
he does this and the server knows that he has, it should be possible to
let him reclaim locks once again.  The problem is that in v4.0, there
doesn't seem to be any way to do this right now.
 
I'm creating an issue in the issue tracker about this.  Solving this
seems to fit in very well with what is necessary to address issues
34,25,17,16.  I intend to address these with a co-ordinated set of
changes and I'll be presenting a proposal to the working group in the
week or so.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4