From: Trond Myklebust <trondmy@hammerspace.com>
To: "bcodding@redhat.com" <bcodding@redhat.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
Subject: Re: [PATCH v2] NFS: Don't skip lookup when holding a delegation
Date: Thu, 16 Jan 2020 16:44:54 +0000 [thread overview]
Message-ID: <3150bc5fb89ceccb53f4625b9e332377a3470ab4.camel@hammerspace.com> (raw)
In-Reply-To: <C5892E37-4731-4AD5-97FE-D8151C289CE9@redhat.com>
On Thu, 2020-01-16 at 11:32 -0500, Benjamin Coddington wrote:
> On 16 Jan 2020, at 11:02, Trond Myklebust wrote:
> > We should need to perform this revalidation once, and only once for
> > that directory, and only if we opened the file using a CLAIM_FH
> > open,
> > or if we opened it through a different hard linked name (and did
> > not
> > create this hard link after we got the delegation).
> >
> > Perhaps we could define a magic value for dentry->d_time that
> > causes us
> > to skip revalidation if and only if we hold a delegation?
>
> Can we put the delegation's change_attr in d_time for dentries that
> have
> been revalided while holding a delegation?
We could, but that seems more complicated because it means you need to
decide whether you are checking the parent inode or your own inode.
It seems easier to just have nfs_force_lookup_revalidate() skip the
magic value so that we know that there are no collisions. Once the
revalidation is done on the dentry holding the delegation, then we can
set dentry->d_time to the magic value, and we're done...
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
prev parent reply other threads:[~2020-01-16 16:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 14:49 [PATCH v2] NFS: Don't skip lookup when holding a delegation Benjamin Coddington
2020-01-16 15:19 ` Benjamin Coddington
2020-01-16 16:02 ` Trond Myklebust
2020-01-16 16:32 ` Benjamin Coddington
2020-01-16 16:44 ` Trond Myklebust [this message]
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=3150bc5fb89ceccb53f4625b9e332377a3470ab4.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=anna.schumaker@netapp.com \
--cc=bcodding@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.