lost dotdot caching pessimizes nfs especially

[rick at snowhite.cis.uoguelph.ca]

[Mike wrote]
> While RFC3530does not use the term "close-to-open consistency"
> (something that I'll address in the NFSv4.1 protocol), it does say:
> 
>    Furthermore, in the absence of open delegation (see the section
> "Open
>    Delegation") two additional rules apply.  Note that these rules are
>    obeyed in practice by many NFS version 2 and version 3 clients.
> 
>    o  First, cached data present on a client must be revalidated after
>       doing an OPEN.  Revalidating means that the client fetches the
>       change attribute from the server, compares it with the cached
>       change attribute, and if different, declares the cached data (as
>       well as the cached attributes) as invalid.  This is to ensure
> that
>       the data for the OPENed file is still correctly reflected in the
>       client's cache.  This validation must be done at least when the
>       client's OPEN operation includes DENY=WRITE or BOTH thus
>       terminating a period in which other clients may have had the
>       opportunity to open the file with WRITE access.  Clients may
>       choose to do the revalidation more often (i.e., at OPENs
>       specifying DENY=NONE) to parallel the NFS version 3 protocol's
>       practice for the benefit of users assuming this degree of cache
>       revalidation.
> 
>       Since the change attribute is updated for data and metadata
>       modifications, some client implementors may be tempted to use the
>       time_modify attribute and not change to validate cached data, so
>       that metadata changes do not spuriously invalidate clean data.
>       The implementor is cautioned in this approach.  The change
>       attribute is guaranteed to change for each update to the file,
>       whereas time_modify is guaranteed to change only at the
>       granularity of the time_delta attribute.  Use by the client's
> data
>       cache validation logic of time_modify and not change runs the
> risk
>       of the client incorrectly marking stale data as valid.
> 
>    o  Second, modified data must be flushed to the server before
> closing
>       a file OPENed for write.  This is complementary to the first
> rule.
>       If the data is not flushed at CLOSE, the revalidation done after
>       client OPENs as file is unable to achieve its purpose.  

Oops, yes, this is in Sec. 9.3. I didn't spot it when I was emailing a few
days ago, but do have code for it in my v4 client (so I must have read it
at some point:-). (fyi, the RFC is only 275 pages)

I'd argue that it contradicts the section I quoted in the last message I
posted, but does spell it out in enough detail that it can't be misinterpreted,
whereas the sections I quoted were kinda vague.

I'll simply re-iterate that this isn't a problem if clients are using
delegations efficiently, for v4, that is. (At this point, none of the v4
clients I am aware of are using delegations to avoid writes on close and
checking against the server upon open, but hopefully it's being worked on.
Since all the interest is in pNFS these days, I'm not so sure, but...)

rick