On Thu, Nov 02, 2023 at 02:59:07PM -0400, Jeff Layton wrote: > 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@xxxxxxxxxx> > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > > > --- > > > 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@xxxxxxxxxx> > > > > > > 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. Hi Jeff, Thanks for this information. Do you mean this case tests passed on nfs due to a bug, and that bug will be fixed soon? I remember yoyang@ wrote this case for a known nfs issue. And this case tests passed on most filesystems. If it won't be suitable for newer nfsd, can we change it for new nfs? Or _notrun it by someone condition? > > 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. Is there any chance (change it a bit) to make this case still works for nfs? Thanks, Zorro > > -- > Jeff Layton <jlayton@xxxxxxxxxx> >
