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

[Elwyn Davies <[e-mail]>]

Hi.

I think we are just about done with this, unless you feel your last 
couple of statements (about stability etc) down the bottom could be 
usefully fed into the document.

I have a feeling that some of this is a bit reliant on the usual 
properties of Unix directories and could be a pig to implement on other 
filesystems - I don't remember enough about directories in NTFS etc (if 
I ever knew) to know whether it would work easily there.  However, since 
this has all been implemented, I'll just go quietly into the night.....

Thanks for your patience!

Please let me have a snapshot of the finished item if you don't submit a 
new version before the IESG meeting.

And now it must be bed time here in the UK!

Good might.
Elwyn

On 02/12/14 00:56, Tom Haynes wrote:
>
>> 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.
>
> I’ve taken this change.
>
>>
>> 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?
>>
>
> No, it does not have to save them.
>
> But the cookies are pretty persistent in the first place. I.e., use some property of either the inode or the dirent to generate the cookie.
>
> As such, the cookie state does not need to be held onto.
>
> And for the life, it actually needs to be “stable” between the opendir() and closedir() call on the client. While we are safe on a client reboot, a client could end up holding onto the DIR pointer for a large indeterminate time.
>