Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Trond Myklebust" <trondmy@hammerspace.com>,
        "Anna Schumaker" <anna.schumaker@netapp.com>
Cc:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: client skips revalidation if holding a delegation
Date:   Tue, 04 Jun 2019 08:41:03 -0400
Message-ID: <6C2EF3B8-568A-41F0-B134-52996457DD7D@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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.

Any thoughts on this?  Any response, even asserting that this is not something
we will fix are welcome.

Thanks,
Ben