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>