On Tue, 2019-06-04 at 08:41 -0400, Benjamin Coddington wrote: > Hey linux-nfs, and especially maintainers, > > I'm still interested in working on a problem raised a couple weeks > ago, but > confusion muddled that discussion and it died: > > If the client holds a read delegation, it will skip revalidation of a > dentry > in lookup. If the file was moved on the server, the client can end > up with > two positive dentries in cache for the same inode, and the dentry > that > doesn't exist on the server will never time out of the cache. > > The client can detect this happening because the directory of the > dentry > that should be revalidated updates it's change attribute. Skipping > revalidation is an optimization in the case we hold a delegation, but > this > optimization should only be used when the delegation was obtained via > a > lookup of the dentry we are currently revalidating. > > Keeping the optimization might be done by tying the delegation to the > dentry. Lacking some (easy?) way to do that currently, it seems > simpler to > remove the optimization altogether, and I will send a patch to remove > it. A delegation normally applies to the entire inode. It covers _all_ dentries that point to that inode too because create, rename and unlink are always atomically accompanied by an inode change attribute. IOW: The proposed restriction is both unnecessary and incorrect. > Any thoughts on this? Any response, even asserting that this is not > something > we will fix are welcome. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
