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?
