Re: [Gen-art] Gen-art LC review of draft-ietf-nfsv4-rfc3530bis-33

[Tom Haynes <[e-mail]>]

> On Dec 1, 2014, at 11:54 AM, Elwyn Davies <[e-mail]> wrote:
> 
> Hi, David.
> 
> Thanks for the response.
> 
> A couple of comments below...
> 
> Regards,
> Elwyn
> 
> On 01/12/14 18:50, David Noveck wrote:
>>    My view (remains) that if the cookie is not tied to the change
>>    attribute of the directory, this makes life difficult for both the
>>    server (what does it send if the data has been changed and how does
>>    it manage maintaining checkpoints -- where a readdir finished --, in
>>    particular if the checkpoint was on an entry that has been deleted),
>>    and the client.
>> 
>> 
>> The cookie is not tied to the change attribute of the directory.
>> 
>> The purpose of the cookie is ensuring that you do a READDIR that
>> encompasses multiple requests:
>> 
>>  * entries that exist during the entire period of the multi-requuest
>>    directory read appear exactly once in the result.
>>  * entries that exists during some part of the period of the
>>    multi-request directory read  appear at most once in the result.
>> 
>> 
>> Basically implementations scan through the directory as it exists on
>> disk and if there is a created entry, the client may or may not see it,
>> depending on where the the new entry happens to be put, with respect to
>> the ongoing scan.  As far as deleted entries, the implementation only
>> has to be able to move on to the next entry if it encouneters an entry
>> marked as deleted.
> 
> OK, so the server has to be clever rather than telling the client to restart the readdir -- I'm not sure this is the right trade-off since the client has to cope with being told the cached cookie is useless (as per Trond's input below) but I guess implementations work this way already and it isn't my call.  In that case I suggest that the last sentence of s15.26.4, para 9, is modified to tell server implementers a bit more clearly what they have to do.  Suggestion:
> OLD:
>   Ideally, the cookie value should not change if the directory is
>   modified since the client may be caching these values.
> NEW:
>   The server SHOULD try to accept cookie values issued with READDIR
>   responses even if the directory has been modified between the
>   READDIR calls but MAY return NFS4ERR_NOT_VALID if this is not
>   possible as might be the case if the server has rebooted in the
>   interim.
> 
> One nasty thought occurs to me regarding the idea that a client caches
> the cookie value(s):  Is the server supposed to maintain the whole
> sequence of cookies for a sequence of READDIRs on a single directory so
> the client can reissue some of the READDIR calls or is it fair enough for the server to throw them away after the client has used them once? And how long should the server hang onto cookie state in normal operation?
> 
>> 
>>    s19.4.1, para 2:
>> 
>>    >    For the purposes of open delegation, READs and WRITEs done without an
>>    >    OPEN are treated as the functional equivalents of a corresponding
>>    >    type of OPEN.  This refers to the READs and WRITEs that use the
>>    >    anonymous stateid.  Therefore, READs or WRITEs with an anonymous
>>    >    stateid done by another client will force the server to recall a
>>    >    OPEN_DELEGATE_WRITE delegation.  A WRITE with an anonymous stateid
>>    >    done by another client will force a recall of OPEN_DELEGATE_READ
>>    >    delegations.
>> 
>> 
>> suggest rewriting this as;
>> 
>>    For the purposes of open delegation, READs and WRITEs done without an
>> 
>>    OPEN (anonymous and read-bypass stateids) are treated as the functional
>>    equivalents of a corresponding type of OPEN. READs and WRITEs done
>>    with an
>>    anonymous stateid done by another client will force the server to
>>    recall a
>> 
>>    OPEN_DELEGATE_WRITE delegation.  A WRITE with an anonymous stateid
>>    done by another client will force a recall of OPEN_DELEGATE_READ
>> 
>>      delegations.  Handling of read-bypass stateid's is identical
>>    except that a READ
>> 
>>    done with a read-bypass stateids will not force a recall of an
>>    OPEN_DELEGATE_READ
>> 
>>    delegation.
>> 

Done


> That sounds good.  It might be useful to add (e.g., to the end of para 1 of s9.6.1:
> "referred to as anonymous stateid and read-bypass stateid respectively.”


Willing to do, just not sure where you want this:


9.6.1.  Client Failure and Recovery

   In the event that a client fails, the server may recover the client's
   locks when the associated leases have expired.  Conflicting locks
   from another client may only be granted after this lease expiration.
   If the client is able to restart or reinitialize within the lease
   period the client may be forced to wait the remainder of the lease
   period before obtaining new locks.

I don’t think that line fits here...