From: Jeff Layton <jlayton@kernel.org>
To: Zorro Lang <zlang@redhat.com>
Cc: fstests@vger.kernel.org, Yongcheng Yang <yoyang@redhat.com>
Subject: Re: [PATCH] generic/732: fix mount option munging
Date: Thu, 02 Nov 2023 14:59:07 -0400 [thread overview]
Message-ID: <f3c14dc1db7b4aa5d348cd0ccdfb63117c6e2d86.camel@kernel.org> (raw)
In-Reply-To: <20231102080640.bntmfreb7t5rh4wp@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
On Thu, 2023-11-02 at 16:06 +0800, Zorro Lang wrote:
> On Wed, Nov 01, 2023 at 02:17:13PM -0400, Jeff Layton wrote:
> > With NFS in particular, we are usually testing with some mount options.
> > Ensure that we preserve those and just add "nosharecache" onto the end
> > of the string.
> >
> > Cc: Yongcheng Yang <yoyang@redhat.com>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > tests/generic/732 | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/generic/732 b/tests/generic/732
> > index 785aac58f361..ae49152e42dc 100755
> > --- a/tests/generic/732
> > +++ b/tests/generic/732
> > @@ -40,7 +40,7 @@ mkdir -p $testdir1 $testdir2
> > # Don't share the data and attribute caches among mount points for NFS.
> > # This caching behavior is necessary to reproduce this issue as we're
> > # checking the alignment of each mount point's own unique cache.
> > -[ "$FSTYP" = "nfs" ] && MOUNT_OPTIONS="-o nosharecache"
> > +[ "$FSTYP" = "nfs" ] && MOUNT_OPTIONS="$MOUNT_OPTIONS -o nosharecache"
>
> Good to me, and looks like the later option replaces the former one, if
> there're same options (e.g. -o sharecache -o nosharecache).
>
> Reviewed-by: Zorro Lang <zlang@redhat.com>
>
>
Thanks, Zorro.
Now that I look more closely, I'm not sure this test will ever pass
properly on NFS. It's basically doing this:
client1: A/f -> B/f
client2: B/f -> A/f
client1: A/f -> B/f
...and the two clients aren't aware of the changes the other is making
(because they were mounted using -o nosharecache). The 3rd rename ends
up thinking that the B/f dentry is still positive, and the rename
syscall fails with EEXIST.
The really confusing bit is that this test passes against servers
running older kernels, because the rename response had the wrong change
info in it and that tricks the client into invalidating the directory
caches when it shouldn't need to do that.
We fixed that in fdd2630a7398 (nfsd: fix change_info in NFSv4 RENAME
replies), and now this test pretty reliably fails when testing against
modern nfsd.
We have some longer term plans to add support for directory delegations
eventually, which may make it easier to keep the caches more coherent,
in this situation, but until then we might want to skip this test.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2023-11-02 18:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-01 18:17 [PATCH] generic/732: fix mount option munging Jeff Layton
2023-11-02 8:06 ` Zorro Lang
2023-11-02 18:59 ` Jeff Layton [this message]
2023-11-05 18:43 ` Zorro Lang
2023-11-05 20:35 ` Jeff Layton
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=f3c14dc1db7b4aa5d348cd0ccdfb63117c6e2d86.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=yoyang@redhat.com \
--cc=zlang@redhat.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