Subject: [nfsv4] Detecting inconsistent state

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Jul 2006 10:43:01 -0400

I've been going through the locking chapter making the extensive
revisions needed to adapt to sessions. As a result, I have been puzzling
over a lot of existing text of this chapter.

Section 5 of draft-03 (in the second non-bulleted paragraph) contains
the following statement, pulled over from RFC3530:

    The client is also able to detect inconsistent state before 
    modifying a file.

So I have two questions:

    What does this mean?

    Is it true?

Obviously, these are related questions :-)

Does anybody have any insight into what is intended here?

One possiblity is that this is related to the following text that has
always puzzled me:

    When the client determines the lease period may have expired, the
    client must mark all locks held for the associated lease as 
    "unvalidated". This means the client has been unable to re-establish

    or confirm the appropriate lock state with the server. As described 
    in the previous section on crash recovery, there are scenarios in 
    which the server may grant conflicting locks after the lease period 
    has expired for a client. When it is possible that the lease period 
    has expired, the client must validate each lock currently held to 
    ensure that a conflicting lock has not been granted. The client may 
    accomplish this task by issuing an I/O request, either a pending I/O

    or a zero-length read, specifying the stateid associated with the 
    lock in question. If the response to the request is success, the 
    client has validated all of the locks governed by that stateid and 
    re-established the appropriate state between itself and the server. 
    If the I/O request is not successful, then one or more of the locks 
    associated with the stateid was revoked by the server and the client

    must notify the owner.

So I've never neen clear why this "must" (although not "MUST") be done.
Is it merely a desire to notify applications as promptly as possible?
That would seem to call for "should" so is something else going on here?

Is there some particular value in noting the revocation as soon as
possible as suggested in that sentence from section 5, quoted above?
However I'm not exactly clear what it is. Also I note that this does not
deal with administrative revocation so that the client "is able to
detect [only a subset of] inconsistent state before modifying a file".
And if you can only do a subset, what is the point of the subset. The
thing that prevents you from modifying the file with inconsistent state
is that the server won't honor the stateid associated with the revoked
lock, not the fact that the client takes note of any inconsistent state.
After all, the validation procedure consists of doing IO's and noting
which ones the server rejects which strongly suggests that the important
thing is the server's state and that the degree of laziness the client
chooses to display in updating his own state to reflect any revocations
is really a quality of implementation issue.

Am I missing something here? I'm inclined to just cut this sentence.

With regard to the paragraph, the complexity of determining when a lease
may have expired can be addressed by SEQUENCE simply returning an
indication when any locks have been revoked. The client could then be
instructed/encouraged to validate his locks to update his state.  In
practice, this would provide very prompt notification of revocation, but
would allow any IO's in that same COMPOUND to be processed and then
rejected if they reference stateid's associated with revoked locks. That
seems fine to me, but it doesn't meet the requirement of the sentence we
are discussing but I don't think RFC3530 ever really did that or that it
is valuable even if you could make it happen. 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4