Re: NFS dentry caching mechanism

[Peter Staubach <staubach@redhat.com>]

Trond Myklebust wrote:

>On Fri, 2006-01-27 at 08:49 -0500, Peter Staubach wrote:
>  
>
>>Well, the need for the stronger consistency in this case reduces the
>>performance benefits, but does not eliminate them.  A GETATTR will
>>always be cheaper than a LOOKUP, especially one that will mostly
>>likely return ENOENT.
>>    
>>
>
>This is still unacceptable: it leads to whole truckloads of unnecessary
>forced GETATTR calls on something like an nfsroot system, where $PATH
>and $LD_LIBRARY_PATH need to be explored every single time the user
>types in a command.
>You appeared to imply that the read-only filesystem case was treated
>differently on Solaris, but that sucks too: a read-only flag just means
>that _you_ can't modify the filesystem, not that others can't.
>
>  
>

With no negative cache, you get LOOKUP operations which are most likely
all going to fail.  With the negative cache, you can trade these failed
LOOKUP operations for GETATTR operations for a net win in CPU on both
the client and the server and also in network utilization because the
GETATTR requests and responses are smaller than the LOOKUP requests and
responses.  You can also retain the consistency semantics to be as
correct as possible.

Read-only file systems are treated differently because it seems a
fairly safe assumption that a file system which is read-only to a client
is probably changing slowly and thus, the normal attribute caching
mechanism is probably sufficient.

If only we knew that a file system was read-only throughout the entire
path and then we could eliminate all of the consistency checks...  :-)

>Furthermore, in cases such as the one that Usha describes, we don't
>actually _care_ about revalidating a negative dentry and/or looking up a
>new dentry. Do it using intents, and you can probably skip all the crap
>in nfs_lookup_revalidate+nfs_lookup: after all you need in order to send
>a valid RMDIR command is the filehandle of the parent, and a name.
>

Well, yes, this would address this one particular aspect, but does not solve
the more general problem.  Bad things can occur when the kernel tells an
application that a file does not exist, when it truly does.  This is bad
because the application can not discover the difference.  Telling an
application that a file does exist when it does not is not quite so bad
because the application can discover the difference.

This situation could be addressed as described, but I suspect that we just
end up in the next situation and eventually needing to fix the problem for
real.

    Thanx...

       ps


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs