linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <6C2EF3B8-568A-41F0-B134-52996457DD7D@redhat.com> (raw)

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

             reply	other threads:[~2019-06-04 12:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-04 12:41 Benjamin Coddington [this message]
2019-06-04 12:56 ` client skips revalidation if holding a delegation Trond Myklebust
2019-06-04 14:10   ` Benjamin Coddington
2019-06-04 14:53     ` Trond Myklebust
2019-06-04 19:00       ` Benjamin Coddington
2019-06-10 14:14         ` Benjamin Coddington
2019-06-10 16:43           ` Trond Myklebust
2019-06-11 17:01             ` Benjamin Coddington
2019-06-10 17:08   ` Olga Kornievskaia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6C2EF3B8-568A-41F0-B134-52996457DD7D@redhat.com \
    --to=bcodding@redhat.com \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).