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