Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Oct 2006 13:59:23 -0700 (PDT)
From:      Mohan Srinivasan <mohan_srinivasan@yahoo.com>
To:        Bruce Evans <bde@zeta.org.au>, fs@freebsd.org
Cc:        mohans@freebsd.org
Subject:   Re: lost dotdot caching pessimizes nfs especially
Message-ID:  <20061015205923.49804.qmail@web30813.mail.mud.yahoo.com>
In-Reply-To: <20061014143825.F1264@epsplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061015205923.49804.qmail>