From: "Benjamin Coddington" <bcodding@redhat.com>
To: "Trond Myklebust" <trondmy@hammerspace.com>
Cc: linux-nfs@vger.kernel.org
Subject: Lookup revalidation for OPEN_CLAIM_FH
Date: Thu, 16 Jan 2020 08:51:22 -0500 [thread overview]
Message-ID: <31B20BC3-A089-47F9-9821-7A3543FF7413@redhat.com> (raw)
Hi Trond,
I'd like to fix up lookup revalidation for v4.1+ when the client is using
OPEN_CLAIM_FH. The fixes a while back for Stan Hu's case do not seem to
improve things for v4.1, and actually make the behavior a bit worse since we
no longer pass through nfs_lookup_verify_inode(), which would catch the
cases where nlink == 0.
Would you accept work to _always_ revalidate the dentry's parent for
CLAIM_FH? Alternatively, it seems that CLAIM_NULL would be preferable for
this case, though I don't know how the client would know when to decide
between them.
Here's a simple reproducer for convenience, I think we've already all agreed
that the behavior we want is for the second open by `cat` to reflect the
results of the move on the server, or at least eventually later opens would
revalidate the dentry:
#!/bin/bash
set -o xtrace
vers=4.1
exportfs -ua
exportfs -o rw,sec=sys,no_root_squash *:/exports
mkdir /mnt/localhost || true
rm -f /exports/file{1,2}
echo this is file 1 > /exports/file1
echo this is file 2 > /exports/file2
mount -t nfs -ov$vers,sec=sys localhost:/exports /mnt/localhost
tail -f /mnt/localhost/file1 &
sleep 1
# this is file 1
cat /mnt/localhost/file1
# overwrite the file on the server:
mv -f /exports/file2 /exports/file1
# this is file 2
cat /mnt/localhost/file1
killall tail
# this is file 2
cat /mnt/localhost/file1
umount /mnt/localhost
Switching the $vers variable between v4.0 and v4.1 in this script shows the
difference in behavior.
Thanks for any advice,
Ben
next reply other threads:[~2020-01-16 13:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 13:51 Benjamin Coddington [this message]
2020-01-16 14:35 ` Lookup revalidation for OPEN_CLAIM_FH Trond Myklebust
2020-01-16 15:13 ` Benjamin Coddington
2020-01-16 15:38 ` Trond Myklebust
2020-01-16 16:21 ` Benjamin Coddington
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=31B20BC3-A089-47F9-9821-7A3543FF7413@redhat.com \
--to=bcodding@redhat.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).