cvs commit: src/sys/nfsclient nfs_vnops.c

[Bruce Evans]

On Mon, 16 Oct 2006, Chuck Lever wrote:

> On 10/16/06, Bruce Evans <bde at zeta.org.au> wrote:
>> On Sun, 15 Oct 2006, Chuck Lever wrote:
>>> [An independent imeout for the access cache isn't useful.]
>> 
>> I'll try removing the special support for the access cache timeout in
>> rc.conf first.
>
> OK.  I can review patches if you think that would help, but I can't
> contribute code at the moment because of IP issues at my current
> employer.  Hopefully that will change soon.

Thanks.  Removing it in rc.conf won't require review :-).

>> > Again, I'm not sure why it is necessary to clear the attribute cache,
>> > when simply verifying that the file object remains the same is all
>> > that is necessary.
>> 
>> An RPC is required to tell if the file changed.  FreeBSD just always
>> uses a Getattr RPC (NFSV3ACCESS_ALL) for this in the v3 case.  Getting
>> all the attributes at once is supposed to be an optimization.
>
> What I'm getting at here is that clearing the cache and verifying the
> cache are different things.  Yes, both still require at least one RPC
> on the wire.  But clearing then replacing the attribute information is
> actually fairly client-CPU-expensive compared to verifying, especially
> since it is done so often.

We're spoiled by CPUs being too fast relative to i/o.

> Another thing to consider is that a LOOKUP is usually more expensive
> for servers than a GETATTR.  If your client has already cached lookup
> results for the file to be opened, you can get away with a GETATTR on
> the parent directory to verify that it has not changed, and that will
> almost always be faster than doing a full LOOKUP.

FreeBSD's client is doing not very good things for Lookup too.  It is
missing caching of negative lookups.  make(1) likes to do a lot of
negative lookups...  NetBSD fixed this in 1997, sigh.

I changed my quick fix to not flush the attribute cache in nfs_close()
(instead of not flushing it in nfs_open()).  This increased the number
of Access RPCs by about 5000, so all the RPC counts are almost exactly
the same as in RELENG_4 and made -current about 2% slower than RELENG_4
instead of only 1% slower.  The current RPC counts for rebuilds after
"make clean cleandepend" are:

make depend:
  Lookup Read Write Access Getattr Other   Total
   14203  548   599  21561     454    97   37462

make:
  Lookup Read Write Create Access Fsstat Other   Total
   19543 2410  5353    442  24241   1742    14   53745

Other statistics show that the kernel build involves about 1700 positive
lookups and that the name cache effectiveness for nfs is only about
80%.  We should be doing only about 2000 Lookups starting from scratch,
and at most about 500 (about the number of object files deleted by
"make clean") for rebuilds.  "make -n" when there is nothing to do
also has a name cache hit rate of about 80%.  Turning of my hack fix
for lost vfs caching of dotdot gives 59000+ Lookups instead of only
19000+, but doesn't affect the hit rate much.

Reducing the Access count will be more interesting when the Lookup
count is reduced to < 2000.  The above access count of 24241 is almost
exactly the same as the number of #include files, so it cannot be
reduced much without losing cto consistency, but without cto consistency,
since almost all opens are for the same few hundred include files, the
Access count can probably be reduced by a factor of 10 too.

Bruce