discuss NFS xfstest failures

* discuss NFS xfstest failures
@ 2019-04-11 17:01 Olga Kornievskaia
  2019-04-16 19:35 ` J. Bruce Fields
  0 siblings, 1 reply; 3+ messages in thread
From: Olga Kornievskaia @ 2019-04-11 17:01 UTC (permalink / raw)
  To: linux-nfs

Hi folks,

We have some output at the wiki --
https://wiki.linux-nfs.org/wiki/index.php/Xfstests -- capturing a data
point of failures (for 4.16 kernel). However, I see many more failures
with the current (5.1-rc1). Wiki output should probably be updated
since xfstest has now 500+ tests. I have done my best to go over the
failures and provide some summary and comments. I'd like to see if the
community has any comments. Anybody else would like to share their
outputs from the xfstests that show other failures?

nfsv4.1
Failures: generic/035 generic/075 generic/091 generic/112 generic/263
generic/294 generic/465 generic/484 nfs/001
Failed 9 of 429 tests
nfsv4.0
Failures: generic/035 generic/075 generic/091 generic/112 generic/263
generic/294 generic/426 generic/465 generic/467 generic/477
generic/484
Failed 11 of 429 tests
nfsv3
Failures: generic/035 generic/258 generic/294 generic/465 generic/467
generic/477 generic/484
Failed 7 of 429 tests

I will first list the ones that are not on the wiki (and grouped by version):

nfs4.1
--- [FIXED] nfs/001 – a regression problem has been resolved with the
latest patch from Chuck addressing the issue.
--- [EXPECTED] generic/075, generic/091, generic/112, generic/263 –
expected failure. Because copy_file_range() is called and passes in as
input and output the same file which is not allowed by the NFSv4.2
spec.
--- [VFS problem] generic/484 this is a VFS failure not to preserve
the lock across execve (as the NFS is just a hook into the VFS)
--- [VFS problem] generic/294 this is again VFS issue that for returns
an error that the test doesn’t expect (test expects EEXIST and gets
ROFS). This error is set by the VFS function finish_open(). However, I
do see some test itself weirdness. The test attempts to remount to a
read-only FS in the middle. Which only translates to new PUTROOTFH. A
test tries to create a file which translates to an NFS operation that
succeeds but the internally VFS fails it as ROFS but file is left
created on the file server.

nfs4.0
--- [FIXED] generic/075, generic/091, generic/112, generic/263 – in
4.0 same function is called and same check that in and out file is the
same and get EINVAL error failing the test. There is a proposed fix
upstream.
--- generic/484 same as 4.1
--- generic/294 same as 4.1

The next tests were present in wiki
--- [EXPECTED] generic/258 (v3) failure only. This is expected because
nfstime3 spec structure defines seconds as “u32” and nfstest4 spec
structure defines as “u64”. So when a large timestamp is set in the
test, v3 wraps it around.
--- [?] generic 426/467/477 (open by handle failures all in v4.0 and
2-out-of-3 in v3, all pass in 4.1. note 426 passes in v3 which is
surprising and makes me think why should 4.0 fail in this case).
Perhaps because 4.0 doesn't support CLAIM_FH this could be considered
expected. but something is fishy here.
--- generic/035 not quiet sure of the exact reason so let's call it expected
--- generic/465 not quiet sure of the exact reason so let's call it expected

As an example, wiki listed a test which probably should have
definitely been running since it's NFS (but wasn't due to a missed
step in a setup)
"nfs/001 [not run] nfs4_setfacl utility required, skipped this test"
It makes me question how many other [not run] tests could also
problems and should have run. Anybody has any ideas how we can get a
'golden' output of what tests are applicable to NFS?

^ permalink raw reply	[flat|nested] 3+ messages in thread