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 <[email protected]> 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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
