Subject: RE: lease expiration, stable storage (was "questions/comments on draft-ietf-nfsv4-rfc3010bis-02-04.txt")

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 19 Aug 2002 19:59:43 -0700

Spencer wrote: 
> On Mon, Noveck, Dave wrote:

 ... Lots of stuff deleted ...

> > I think from a protocol point of view, V4 is able to deal with this
> > situation.  The server can figure out what is going on and record enough
> > information in stable storage to prevent erroneous reclaims.  Clearly
> > doing that is a good thing, but the question is how strictly should
> > the spec mandate that good behavior.
>
> Agreed.  My current opinion is that if the server is offering advisory
> locking only, then it doesn't need to do the extra work.  If mandatory
> locking is being used, then it should so something minimal as I
> suggested and that burden shouldn't be too much greater than for
> v2/v3.

Even a server supporting only advisory byte-range locks will support
mandatory share reservations.  I consider share reservations inherently
mandatory in V4 since the server is supposed to enforce them based on 
the stateids passed in READs and WRITEs.

For most, but not all cases of share reservation conflict, the client
can protect itself against this problem by checking the change attribute
upon reclaim.  The cases in which it can't do this are:

      Conflicts that involve DENY=READ since there may be no change to
      the file for the client to key on.  It's hard to be really worried
      about this case.

      Asymmetric conflicts between the reclaim of an OPEN for WRITE and
      a conflicting OPEN for READ,DENY=WRITE, since the reclaiming client
      will not see any change if there were a conflicting OPEN that
      intervened.  In this case, the reclaiming client is not going to 
      harmed.  The client doing the conflicting open has more of a beef
      but he could have encountered the file after the client rebooted,
      so I don't think he will really be harmed either.

      There are some cases in which the client will not be a position to
      know the proper change attr.  If a client issues a WRITE and doesn't
      get a response, but the WRITE actually happened on the server, the
      change attr upon reclaim will have a value different from all 
      the ones that the client has seen.  In that case, it would erroneously
      not try to reclaim, at least when it was open with DENY specifying
      WRITE (or ALL).

So looking at those three cases, my conclusion is it would be would be a mistake
to hold up protocol implementation until these issues are truly solved in 
all servers.  I would treat this as a quality-of-implementation issue.

On the other hand, if the server is implementing mandatory byte-range locking, 
it had better address this issue, since in that case, client self-help is not
really possible at all.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 19 Aug 2002 22:25:23 -0500

> it had better address this issue, since in that case, client self-help is not

I tend to agree.  Everything we have discussed does not require an
over-the-wire change.  Therefore, if we change our minds after the
current draft reaches proposed, we can still document required
behavior in subsequent RFCs.

So it seems we have some work to do to incorporate the suggestions you
made in the other thread and the suggestion here (if we have
consensus).  I would suggest that we remove the
quality-of-implementation statements from the current draft and post a
discussion of the issue in an implementation FAQ on www.nfsv4.org as
well as pointing to this archive.

-- 
Spencer