On Feb 6, 2014, at 23:30, NeilBrown <neilb@xxxxxxx> wrote: > On Thu, 06 Feb 2014 17:12:59 -0500 Trond Myklebust > <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > >> On Thu, 2014-02-06 at 13:51 +1100, NeilBrown wrote: >>> On Thu, 6 Feb 2014 13:45:39 +1100 NeilBrown <neilb@xxxxxxx> wrote: >>> >>> >>>> The change to nfs_update_inode fixes an issue that had me stumped for a >>>> while. It was still sending lots of GETATTR requests even after it had >>>> switched to READDIRPLUS instead of using cached info. So that might be a >>>> genuine bug that should be fixed independently of this patch. >>> >>> I managed to post the wrong version of the patch, which didn't have this >>> change. Sorry. >>> >>> Here is the real one. >>> >>> NeilBrown >> >> Hi Neil, >> >> Is there any reason why this patch couldn't just be replaced with the >> following? > > Well.... the following doesn't make any change in my test case. :-( > > In my test case there is a large directory on the server which doesn't change. > The client sends lots of requests to see if it has changed, but it hasn't. > (Tested with the labeled-NFS-regression fix applied) > > Your patch only changes behaviour if nfs_force_lookup_revalidate is called, > and that is only called when NFS_ATTR_FATTR_CHANGE is set, or when an NFSv4 > client modifies the directory. Neither of those are happening. Right, but I really do not know how to fix that case. I read your patch as saying: "If we're revalidating a dentry and we find that the directory has not changed but that the dentry’s inode needs revalidation, then invalidate that directory's attribute, acl and readdir cached data. Then drop the dentry”. I have a hard time seeing how that can be beneficial. If we were to modify it, to only invalidate the readdir cached data, then that might improve matters, but it is still hard for me to see how a single inode needing revalidation can justify a full re-read of the parent directory in the general case. You may end up rereading thousands of readdir entries from the server just because someone did a path lookup. _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
