Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 May 2010 20:45:13 -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.1005202036570.15248@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.
>
Well, it sounds like a good theory. Something like:
- VOP_LOOKUP() locks the vnode, which is then passed to VOP_OPEN() and
   since it is locked, other threads can't perform VOPs on the vp.

I ran a single pass of a kernel "make cleandepend; make depend; make"
here (1 without the patch and one with the patch). Now, it could be
random variation, but since the other RPC counts changed by < 1%, I
suspect not. (I'll run another pass of each to see how much variation
I see w.r.t. Getattr.)

Here's the counts for the 5 RPCs I think might be interesting:
RPC		Count without patch	Count with patch
Getattr		590936			625987		+5.9%
Lookup		157194			157528
Access		59040			59690		+1.1%
Read		70585			70586
Write		112531			112530

I let you know what another pass of each gives, but it looks like
it has caused an increase in RPC cnts. I don't know if the increase
is enough to deter adding the patch, but it might be worth exploring
it more?

rick




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