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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
