[PATCH] Better handling of stale filehandles in open() in the NFS client

[Rick Macklem]

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