Re: [PATCH] NFSD: Fill in WCC data for REMOVE, RMDIR, MKNOD, and MKDIR

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Jul 08, 2010 at 11:02:12AM -0400, Chuck Lever wrote:
> On 07/ 7/10 05:10 PM, J. Bruce Fields wrote:
> >On Tue, Jul 06, 2010 at 04:53:34PM -0400, Chuck Lever wrote:
> >>Some well-known NFSv3 clients drop their directory entry caches when
> >>they receive replies with no WCC data.
> >
> >Can we include any more details?  (And/or a simple test case that
> >demonstrates the difference?)
> 
> I have a version of this patch with a much more comprehensive
> description which I can post later today.

Thanks, that would be interesting.

(Though note the version you posted is already applied for 2.6.36.)

--b.

> As for a test case... among other things, I untarred a large tarball
> on a Mac OS 10.6 NFS client, and, once the server was fixed, it went
> as quickly as you would expect.  Before, it took much longer.
> 
> >>Without this data, they
> >>employ extra READ, LOOKUP, and GETATTR requests to ensure their
> >>directory entry caches are up to date, causing performance to suffer
> >>needlessly.
> >>
> >>In order to return WCC data, our server has to have both the pre-op
> >>and the post-op attribute data on hand when a reply is XDR encoded.
> >>The pre-op data is filled in when the incoming fh is locked, and the
> >>post-op data is filled in when the fh is unlocked.
> >>
> >>Unfortunately, for REMOVE, RMDIR, MKNOD, and MKDIR, the directory fh
> >>is not unlocked until well after the reply has been XDR encoded.
> >
> >So it wasn't happening until an fh_put() was done in .pc_release()?
> 
> Correct.