Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B28D1A6EF1 for ; Tue, 2 Dec 2014 09:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVUIHNCDARry for ; Tue, 2 Dec 2014 09:34:34 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0BA1A6EE6 for ; Tue, 2 Dec 2014 09:34:30 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id x69so9173025oia.26 for ; Tue, 02 Dec 2014 09:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=awEoUHVh4HHX5FrKHlUhg2nQ1d+DeQHwCjeGfvLKndQ=; b=iPI1gr95mdRC6YX5Ih6hzDkQyV2FgnrbRJtMe3CCfXy5jnU9wptcBvBRLKxqEyzN4y 5a5s51rW20owl70TYqRSPImeL1O9B+yL4rIGp2+fMzJdoeDcCyQGc2aMtXjRoE01v7SY D35gwNTzrvhgQgacqyx59PsQ2volkFEtxDs8uKV809oPTIgYZx+ZFig23X3geJIiirNF f8/ydcC5za5iNJB8KizBp3Z3Y7bS2GqKXeOuJkC8aj2GTKp9P2ngDnqh2Hxl/RE7D8P5 tr9kXOtJjOi8lwzchIDKEZLBL8CvBh5jyaVlp1uHdypQa5Z8z6NR0RvTQpII3muXBeIm ecdw== MIME-Version: 1.0 X-Received: by 10.202.181.213 with SMTP id e204mr146135oif.117.1417541669490; Tue, 02 Dec 2014 09:34:29 -0800 (PST) Received: by 10.182.5.198 with HTTP; Tue, 2 Dec 2014 09:34:29 -0800 (PST) In-Reply-To: <547DEBAF.9010907@dial.pipex.com> References: <54627625.9050909@dial.pipex.com> <7E1914F4-413F-4F7E-BE9A-C941FBDD422B@primarydata.com> <5465143D.6020604@dial.pipex.com> <47860B2D-1977-4062-9775-10463F7030B9@primarydata.com> <546B0F4F.3060504@dial.pipex.com> <547C7E2B.10305@dial.pipex.com> <547CC75C.7010909@dial.pipex.com> <1F2B554C-4C7C-4BF0-B078-AA7988F7B0AF@primarydata.com> <547DC609.9070104@dial.pipex.com> <547DEBAF.9010907@dial.pipex.com> Date: Tue, 2 Dec 2014 12:34:29 -0500 Message-ID: From: David Noveck To: Elwyn Davies Content-Type: multipart/alternative; boundary=001a113cd1acaa16cb05093f2313 Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/BJQunJfbsIa_TONqqTrLIlLJfsk Cc: "gen-art >> General area reviewing team" , Barry Leiba , Tom Haynes Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-nfsv4-rfc3530bis-33 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:34:39 -0000 --001a113cd1acaa16cb05093f2313 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > cookies previously given out. When such a situation occurs, the server should modify the cookie verifier so as to > accept cookies which would otherwise no longer be vali ''accept cookies'" --> "disallow use of cookies' On Tue, Dec 2, 2014 at 11:41 AM, Elwyn Davies wrote= : > Hi, David. > > Excellent. I think some suitable combination of your words below would > fill the bill. > > The point about the very large directories is well taken - I hadn't > grokked that previously. > > I guess the update should go in s15.26.5 after para 1: > > Something like: > > ----------------- > > As there is no way for the client to indicate that a cookie value once > received, will not be subsequently used, server implementations should > avoid schemes that allocate memory corresponding to a returned cookie. Su= ch > allocation can be avoided if the server bases cookie values on a value su= ch > as the offset within the directory where the scan is to be resumed. > > Cookies generated by such techniques should be designed to remain valid > despite modification of the associated directory. If a server were to > invalidate a cookie because of a directory modification, READDIR's of lar= ge > directories might never finish. > > If a directory is deleted after the client has carried out one or more > READDIR operations on the directory, the cookies returned will become > invalid but the server does not need to be concerned as the directory fil= e > handle used previously would have become stale and would be reported as > such on subsequent READDIR operations. The server would not need to chec= k > the cookie verifier in this case. > > However, certain re-organization operations on a directory (including > directory compaction) may invalidate READDDIR cookies previously given > out. When such a situation occurs, the server should modify the cookie > verifier so as to accept cookies which would otherwise no longer be valid= . > > ------------------- > > Aside: handling reorganization without creating state sounds challenging > but life wouldn't be interesting without challenges! :-) > > A couple of nits that got missed from yesterday: > > s5.4, 2nd bullet labelled '1.': s/common to all object within given file > system./common to all objects within the given file system./ > > s9.1.3, last sentence: s/an can be treated as later./and can be treated a= s > later./ > ^^^^ > > > With something like the above, I think we are done. > > Congratulations! I hope this gets to be an RFC RSN. > > Cheers, > Elwyn > > > > > > On 02/12/14 14:56, David Noveck wrote: > >> Hence, NFS has no equivalent of the "directory stream" referred to >> in the Unix manual pages. Furthermore you don't 'open' a directory >> in NFSv4, you just give it the filehandle. >> >> >> Correct. NFSv4 just took over the NFSv3 approach to reading directories >> and NFSv3 doesn't support open/close at all. >> >> However the lack of a closedir equivalent means that the server has >> no idea when the client has finished with the READDIR cookie(s). >> >> Right. >> >> I think it would be helpful to give some advice on what the server >> should do to avoid a build up of probably useless state. >> >> how about: >> >> As there is no way for the client to indicate that a cookie value >> once received, will not be subsequently used, serer implementations >> should avoid schemes that allocate memory corresponding to a >> returned cookie. Such allocation can be avoided if the server bases >> cookie values on a value such as the offset within the directory >> wher the scan is to be resumed. >> >> >> Given the usual usage of READDIR, I would expect that once a call >> has returned eof<-TRUE, the client will in almost all cases be done >> and the state for the (client,directory) pair can be discarded. >> >> >> Except there is no state for client,directory pair. The spec does not >> mandate that such state be maintained, and i don't know of server that >> maintain that sort of state. NFSv4. servers follow the NFSv3 practice, >> where client state/per se/ did not exist. >> >> However, there might be cases where the call has to be rerun due to >> comms failure I suppose, so maybe after a number of calls at eof? >> Presumably there also ought to be some sort of timeout (like if the >> leases expire??) I have no idea what current implementations do her= e. >> >> None of these situations arise since there is no per--client readdir >> state. >> >> >> >> Crafting a couple of sentences to mention these three items (deletion, >> modification and stale state) would IMO be helpful. It would certainly >> have helped me!. >> >> suggestions: >> >> * *deletion* >> >> cookies return by READDIR become invalid when the directory is >> removed but the server is not obliged for check for this situation >> or check the cookie verifier since the directory handle will become >> stale. >> >> * *modification* >> >> Cookies generated by such techniques should reaiin valid despite >> modification of the associated directory. If a server were to >> invalidate a cookie because of a directory modification, READDIR's >> of large directories might never finish. >> >> * *stale state* >> >> I think it is clear from the text above that there is no state to >> become stale. Not sure what else you can say. >> >> * *directory reorganization* >> >> certain re-organization operation on a directory (including >> directory compaction) may invalidate READDDIR cookies >> previously given out. when these situation ocur, the server should >> modify the cookie verifier to accepting cookies which are no longer >> valid. >> >> >> On Tue, Dec 2, 2014 at 9:00 AM, Elwyn Davies > > wrote: >> >> Hi. >> >> Sorry to keep harping on about READDIR, but... >> >> Tom's comment about opendir/closedir at the end of the mail nbelow >> obviously triggered something in my brain overnight, 'cos I woke up >> realizing that I wasn't correctly understanding the semantics here. >> >> Please bear with while I parade my naivete :-( >> >> Having refreshed my memory on the semantics of reading directories >> in Unix and checked back on NFSv4, I realized that NFSv4 doesn't >> have the equivalents of opendir and closedir. >> >> Hence, NFS has no equivalent of the "directory stream" referred to >> in the Unix manual pages. Furthermore you don't 'open' a directory >> in NFSv4, you just give it the filehandle. >> >> So, the case of the directory getting deleted under your feet >> between READDIR calls presumably just results in a NFS4ERR_STALE >> error on the next READDIR call and the issue of whether the cookie >> is valid is moot. It is then up to the client to map this into local >> OS behaviour. >> >> This means that only the directory modification case is relevant to >> the cookie validity issue, and I understand the comment that David >> was making yesterday more clearly now. >> >> However the lack of a closedir equivalent means that the server has >> no idea when the client has finished with the READDIR cookie(s). I >> think it would be helpful to give some advice on what the server >> should do to avoid a build up of probably useless state. >> >> Given the usual usage of READDIR, I would expect that once a call >> has returned eof<-TRUE, the client will in almost all cases be done >> and the state for the (client,directory) pair can be discarded. >> However, there might be cases where the call has to be rerun due to >> comms failure I suppose, so maybe after a number of calls at eof? >> Presumably there also ought to be some sort of timeout (like if the >> leases expire??) I have no idea what current implementations do her= e. >> >> Crafting a couple of sentences to mention these three items >> (deletion, modification and stale state) would IMO be helpful. It >> would certainly have helped me! >> >> Regards, >> Elwyn >> >> On 02/12/14 00:56, Tom Haynes wrote: >> >> >> On Dec 1, 2014, at 11:54 AM, Elwyn Davies >> > 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=E2=80=99ve 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 =E2=80=9Cstable=E2=80= =9D 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. >> >> >> --001a113cd1acaa16cb05093f2313 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> cookies previously given out.=C2=A0 When such a situation occurs, th= e server should modify the cookie verifier so as to
> =C2=A0accept=C2=A0cookies whi= ch would otherwise no longer be vali

''accept cookies'" --> =C2=A0"dis= allow use of cookies'

On Tue, Dec 2, 2014 at 11:41 AM, Elwyn Dav= ies <elwynd@dial.pipex.com> wrote:
Hi, David.

Excellent.=C2=A0 I think some suitable combination of your words below woul= d fill the bill.

The point about the very large directories is well taken - I hadn't gro= kked that previously.

I guess the update should go in s15.26.5 after para 1:

Something like:

-----------------

As there is no way for the client to indicate that a cookie value once rece= ived, will not be subsequently used, server implementations should avoid sc= hemes that allocate memory corresponding to a returned cookie. Such allocat= ion can be avoided if the server bases cookie values on a value such as the= offset within the directory where the scan is to be resumed.

Cookies generated by such techniques should be designed to remain valid des= pite modification of the associated directory.=C2=A0 If a server were to in= validate a cookie because of a directory modification, READDIR's of lar= ge directories might never finish.

If a directory is deleted after the client has carried out one or more READ= DIR operations on the directory, the cookies returned will become invalid b= ut the server does not need to be concerned as the directory file handle us= ed previously would have become stale and would be reported as such on subs= equent READDIR operations.=C2=A0 The server would not need to check the coo= kie verifier in this case.

However, certain re-organization operations on a directory (including direc= tory compaction) may invalidate READDDIR cookies previously given out.=C2= =A0 When such a situation occurs, the server should modify the cookie verif= ier so as to accept cookies which would otherwise no longer be valid.

-------------------

Aside: handling reorganization without creating state sounds challenging bu= t life wouldn't be interesting without challenges! :-)

A couple of nits that got missed from yesterday:

s5.4, 2nd bullet labelled '1.': s/common to all object within given= file system./common to all objects within the given file system./

 s9.1.3, last sentence: s/an can be treated as later./and can be treated as = later./
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0^^^^


With something like the above, I think we are done.

Congratulations!=C2=A0 I hope this gets to be an RFC RSN.

Cheers,
Elwyn





On 02/12/14 14:56, David Noveck wrote:
=C2=A0 =C2=A0 Hence, NFS has no equivalent of the "directory stream&qu= ot; referred to
=C2=A0 =C2=A0 in the Unix manual pages.=C2=A0 Furthermore you don't = 9;open' a directory
=C2=A0 =C2=A0 in NFSv4, you just give it the filehandle.


Correct.=C2=A0 NFSv4 just took over the NFSv3 approach to reading directori= es
and NFSv3 doesn't support open/close at all.

=C2=A0 =C2=A0 However the lack of a closedir equivalent means that the serv= er has
=C2=A0 =C2=A0 no idea when the client has finished with the READDIR cookie(= s).

Right.

=C2=A0 =C2=A0 =C2=A0 I think it would be helpful to give some advice on wha= t the server
=C2=A0 =C2=A0 should do to avoid a build up of probably useless state.

how about:

=C2=A0 =C2=A0 As there is no way for the client to indicate that a cookie v= alue
=C2=A0 =C2=A0 once received, will not be subsequently used, serer implement= ations
=C2=A0 =C2=A0 should avoid schemes that allocate memory corresponding to a<= br> =C2=A0 =C2=A0 returned cookie.=C2=A0 Such allocation can be avoided if the = server bases
=C2=A0 =C2=A0 cookie values on a value such as the offset within the direct= ory
=C2=A0 =C2=A0 wher the scan is to be resumed.


=C2=A0 =C2=A0 Given the usual usage of READDIR, I would expect that once a = call
=C2=A0 =C2=A0 has returned eof<-TRUE, the client will in almost all case= s be done
=C2=A0 =C2=A0 and the state for the (client,directory) pair can be discarde= d.


Except there is no state for=C2=A0 client,directory pair.=C2=A0 The spec do= es not
mandate that such state be maintained, and i don't know of server that<= br> maintain that sort of state.=C2=A0 NFSv4. servers follow the NFSv3 practice= ,
 where client state/per se/ did not exist.

=C2=A0 =C2=A0 However, there might be cases where the call has to be rerun = due to
=C2=A0 =C2=A0 comms failure I suppose, so maybe after a number of calls at = eof?
=C2=A0 =C2=A0 Presumably there also ought to be some sort of timeout (like = if the
=C2=A0 =C2=A0 leases expire??)=C2=A0 I have no idea what current implementa= tions do here.

None of these situations arise since there is no per--client readdir state.=



Crafting a couple of sentences to mention these three items (deletion,
modification and stale state) would IMO be helpful.=C2=A0 It would certainl= y
have helped me!.

suggestions:

 =C2=A0 * *deletion*

=C2=A0 =C2=A0 cookies return by READDIR become invalid when the directory i= s
=C2=A0 =C2=A0 removed but the server is not obliged for check for this situ= ation
=C2=A0 =C2=A0 or check the cookie verifier since the directory handle will = become
=C2=A0 =C2=A0 stale.

 =C2=A0 * *modification*

=C2=A0 =C2=A0 Cookies generated by such techniques should reaiin valid desp= ite
=C2=A0 =C2=A0 modification of the associated directory.=C2=A0 If a server w= ere to
=C2=A0 =C2=A0 invalidate a cookie because of a directory modification, READ= DIR's
=C2=A0 =C2=A0 of large directories might never finish.

 =C2=A0 * *stale state*

=C2=A0 =C2=A0 I think it is clear from the text above that there is no stat= e to
=C2=A0 =C2=A0 become stale.=C2=A0 Not sure what else you can say.

 =C2=A0 * *directory reorganization*

=C2=A0 =C2=A0 certain re-organization operation on a directory (including =C2=A0 =C2=A0 directory compaction) may invalidate READDDIR cookies
=C2=A0 =C2=A0 previously given out.=C2=A0 when these situation ocur, the se= rver should
=C2=A0 =C2=A0 modify the cookie verifier to accepting cookies which are no = longer
=C2=A0 =C2=A0 valid.


On Tue, Dec 2, 2014 at 9:00 AM, Elwyn Davies <elwynd@dial.pipex.com
<= div class=3D"h5"> <mailto:elwyn= d@dial.pipex.com>> wrote:

=C2=A0 =C2=A0 Hi.

=C2=A0 =C2=A0 Sorry to keep harping on about READDIR, but...

=C2=A0 =C2=A0 Tom's comment about opendir/closedir at the end of the ma= il nbelow
=C2=A0 =C2=A0 obviously triggered something in my brain overnight, 'cos= I woke up
=C2=A0 =C2=A0 realizing that I wasn't correctly understanding the seman= tics here.

=C2=A0 =C2=A0 Please bear with while I parade my naivete :-(

=C2=A0 =C2=A0 Having refreshed my memory on the semantics of reading direct= ories
=C2=A0 =C2=A0 in Unix and checked back on NFSv4, I realized that NFSv4 does= n't
=C2=A0 =C2=A0 have the equivalents of opendir and closedir.

=C2=A0 =C2=A0 Hence, NFS has no equivalent of the "directory stream&qu= ot; referred to
=C2=A0 =C2=A0 in the Unix manual pages.=C2=A0 Furthermore you don't = 9;open' a directory
=C2=A0 =C2=A0 in NFSv4, you just give it the filehandle.

=C2=A0 =C2=A0 So, the case of the directory getting deleted under your feet=
=C2=A0 =C2=A0 between READDIR calls presumably just results in a NFS4ERR_ST= ALE
=C2=A0 =C2=A0 error on the next READDIR call and the issue of whether the c= ookie
=C2=A0 =C2=A0 is valid is moot. It is then up to the client to map this int= o local
=C2=A0 =C2=A0 OS behaviour.

=C2=A0 =C2=A0 This means that only the directory modification case is relev= ant to
=C2=A0 =C2=A0 the cookie validity issue, and I understand the comment that = David
=C2=A0 =C2=A0 was making yesterday more clearly now.

=C2=A0 =C2=A0 However the lack of a closedir equivalent means that the serv= er has
=C2=A0 =C2=A0 no idea when the client has finished with the READDIR cookie(= s).=C2=A0 I
=C2=A0 =C2=A0 think it would be helpful to give some advice on what the ser= ver
=C2=A0 =C2=A0 should do to avoid a build up of probably useless state.

=C2=A0 =C2=A0 Given the usual usage of READDIR, I would expect that once a = call
=C2=A0 =C2=A0 has returned eof<-TRUE, the client will in almost all case= s be done
=C2=A0 =C2=A0 and the state for the (client,directory) pair can be discarde= d.
=C2=A0 =C2=A0 However, there might be cases where the call has to be rerun = due to
=C2=A0 =C2=A0 comms failure I suppose, so maybe after a number of calls at = eof?
=C2=A0 =C2=A0 Presumably there also ought to be some sort of timeout (like = if the
=C2=A0 =C2=A0 leases expire??)=C2=A0 I have no idea what current implementa= tions do here.

=C2=A0 =C2=A0 Crafting a couple of sentences to mention these three items =C2=A0 =C2=A0 (deletion, modification and stale state) would IMO be helpful= .=C2=A0 It
=C2=A0 =C2=A0 would certainly have helped me!

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Elwyn

=C2=A0 =C2=A0 On 02/12/14 00:56, Tom Haynes wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Dec 1, 2014, at 11:54 AM, Elwy= n Davies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <elwynd@dial.pipex.com <mailto:elwynd@dial.pipex.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi, David.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks for the response.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A couple of comments below...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Elwyn

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 01/12/14 18:50, David Noveck w= rote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0My view (remains) that if the cookie is not tied to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the change
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0attribute of the directory, this makes life
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 difficult for both = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0server (what does it send if the data has been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changed and how doe= s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0it manage maintaining checkpoints -- where a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 readdir finished --= , in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0particular if the checkpoint was on an entry that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has been deleted),<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0and the client.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The cookie is not t= ied to the change attribute of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 directory.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The purpose of the = cookie is ensuring that you do a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 READDIR that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encompasses multipl= e requests:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* entr= ies that exist during the entire period of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multi-requuest
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0directory read appear exactly once in the result.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* entr= ies that exists during some part of the period
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0multi-request directory read=C2=A0 appear at most once
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the result.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Basically implement= ations scan through the directory as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it exists on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 disk and if there i= s a created entry, the client may or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may not see it,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 depending on where = the the new entry happens to be put,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with respect to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the ongoing scan.= =C2=A0 As far as deleted entries, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation only=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has to be able to m= ove on to the next entry if it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encouneters an entr= y
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 marked as deleted.<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OK, so the server has to be cleve= r rather than telling the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client to restart the readdir -- = I'm not sure this is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 right trade-off since the client = has to cope with being told
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the cached cookie is useless (as = per Trond's input below)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 but I guess implementations work = this way already and it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 isn't my call.=C2=A0 In that = case I suggest that the last
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sentence of s15.26.4, para 9, is = modified to tell server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementers a bit more clearly w= hat they have to do.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Suggestion:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OLD:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ideally, the cookie= value should not change if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 directory is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 modified since the = client may be caching these values.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NEW:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The server SHOULD t= ry to accept cookie values issued
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with READDIR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 responses even if t= he directory has been modified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 between the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 READDIR calls but M= AY return NFS4ERR_NOT_VALID if this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possible as might b= e the case if the server has rebooted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interim.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I=E2=80=99ve taken this change.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One nasty thought occurs to me re= garding the idea that a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client caches
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the cookie value(s):=C2=A0 Is the= server supposed to maintain the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 whole
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sequence of cookies for a sequenc= e of READDIRs on a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 directory so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the client can reissue some of th= e READDIR calls or is it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fair enough for the server to thr= ow them away after the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 client has used them once? And ho= w long should the server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hang onto cookie state in normal = operation?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 No, it does not have to save them.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 But the cookies are pretty persistent in the fi= rst place. I.e.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use some property of either the inode or the di= rent to generate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the cookie.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 As such, the cookie state does not need to be h= eld onto.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 And for the life, it actually needs to be =E2= =80=9Cstable=E2=80=9D between the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opendir() and closedir() call on the client. Wh= ile we are safe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on a client reboot, a client could end up holdi= ng onto the DIR
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pointer for a large indeterminate time.



--001a113cd1acaa16cb05093f2313--