Re: client skips revalidation if holding a delegation

[Trond Myklebust <trondmy@hammerspace.com>]

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@hammerspace.com