Date: Fri, 21 May 2010 11:40:50 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@freebsd.org> Cc: Rick Macklem <rmacklem@freebsd.org>, Robert Watson <rwatson@freebsd.org>, fs@freebsd.org Subject: Re: [PATCH] Better handling of stale filehandles in open() in the NFS client Message-ID: <Pine.GSO.4.63.1005211133040.25303@muncher.cs.uoguelph.ca> In-Reply-To: <201005200922.17245.jhb@freebsd.org> References: <201005191144.00382.jhb@freebsd.org> <Pine.GSO.4.63.1005192004370.8867@muncher.cs.uoguelph.ca> <201005200922.17245.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 May 2010, John Baldwin wrote: > > It doesn't change the RPC count because of changes that Mohan added to the > NFS client a while ago so that nfs_open() doesn't invalide the attribute > cache during nfs_open() if it was already updated via nfs_lookup() during > the same system call. With Mohan's changes in place, all this change does > is move the GETATTR/ACCESS RPC earlier in the case of a namecache hit. > I tried another kernel build with and without the patch and an about 6% increase in Getattr RPCs seems real. (The 1% increase in Access RPCs was not related to the patch and appears to have happened because I didn't do an unmount/mount between runs, which results in RPC cnts changing by up to 1%.) I have no idea whether or not an approx. 6% increase in Getattr RPCs for this case is enough of a concern w.r.t. patch that it needs to be looked at further? Btw, I'm doing the tests on a pretty recent -current kernel which appears to do shared vnode locks for read opens, which might explain why the Getattr cnt changes? (You're patch had quite different line #s, so I assume it wasn't against -current?) Have fun with it, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.1005211133040.25303>