lost dotdot caching pessimizes nfs especially

Mohan Srinivasan mohan_srinivasan at yahoo.com
Sun Oct 15 14:08:46 PDT 2006


Bruce, 

Not sure if you are committing a change eliminating that line in nfs_open() 
that clears the attrcache. But if you're doing so, please test to make sure
you don't break close-to-open consistency.

If you're going to optimize, please give priority to correctness first.

If you are convinced that a lookup() will fetch fresh attrs in *all* cases, then
by all means go ahead and remove that line.

mohan

--- Mohan Srinivasan <mohan_srinivasan at yahoo.com> wrote:

> Bruce
> 
> Defending the "silliness" of the first of the 2 changes you cite as I am the author of that 
> change. Just got back from a short break and am still catching up on this thread.
> 
> The clearing of the attrcache on nfs_open() is a requirement for close-to-open
> consistency, and this change fixed bugs that we saw internally relating to 
> close-to-open consistency.
> 
> > and associated changes give silly behaviour that almost doubles the
> > number of Access RPCs.  One of the associated changes clears n_attrstamp
> > on close().  Then on open(), since lookup() is called before the above
> > is reached, nfs_access_otw() has always just been called, and the above
>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > forces another call.
> 
> That is not true with NFSv2 which doesn't have an access call, in which case
> nfsspec_access() calls VOP_GETATTR, which may or may not go over the wire.
> 
> Also, what would happen with NFSv3 if we get an access cache hit ?
> 
> If lookup() can be made to pass a flag into nfs_open() that an otw getattr was
> done, then we can eliminate the clearing of the attrcache in nfs_open(). But
> absent that flag, I don't see how you can eliminate the fetch of fresh attributes
> in nfs_open().
> 
> mohan
> 



More information about the freebsd-fs mailing list