Re: [PATCH 0/3] Intro: Better handling coarse-grained timestamps

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Tue, 2008-01-15 at 20:55 -0500, Bob Bell wrote:
> On Tue, Jan 15, 2008 at 11:27:01AM -0500, Bob Bell wrote:
> >Secondly, a modification to the kernel has been made to disable the 
> >caching of negative dentries when the NFS_MOUNT_NONEGDE flag is set.  
> >Note that this does nothing to address outdated information being 
> >returned by readdir().  However, it does allow a file to be open()ed or 
> >lstat()ed if the filename is known.  Because this has a potential 
> >performance impact, it is left as an option for the user to select.
> 
> Someone pointed me to this page on NFSv4.1 directory delegations: 
> http://wiki.linux-nfs.org/wiki/index.php/NFSv4.1_Directory_Delegations
> 
> I found the following quotes intriguing:
> 
> "Even though the directories along the path are cached, [without 
> directory delegations] negative dentry caching is not allowed because it 
> potentially violates close-to-open consistency semantics."

Negative dentry caching has nothing whatsoever to do with close-to-open
semantics.

> "Close-to-open consistency currently requires that even in a case where 
> previous LOOKUPs or OPENs for a given file have recently and repeatedly 
> failed, subsequent LOOKUPs and OPENs must nevertheless be sent to the 
> server (i.e., negative caching provides no benefit in those cases)."

Nope. All close-to-open cache consistency requires is that the client
revalidate the file/directory cached data upon an open()/opendir() call
by checking the inode mtime and/or change attribute (NFSv4 only).

I think we need to revisit that wiki entry...

Trond