I'm embarrassed that I don't do anything close to this for my weekly
nfs-ganesha merges...
I'd love to see some tools to make it easier to do more testing.
I wish there was a solution that didn't require two hosts for testing NFSv3
locks against nfs-ganesha.
I need to get back to the pynfs v3 tests...
Another test I have run is pjdfstests, which there seem to be multiple
versions of, I have repos of two versions here that are Ganesha aware. These
tests include a lot of POSIX compliance so will catch permission issues and
other POSIX oddities. I also haven't run them in ages...
https://github.com/ffilz/ntfs-3g-pjd-fstest
https://github.com/ffilz/pjdfstest
The nfs-ganesha tree also has a tool to help write lock tests (and can be
used for a few other things too - I recently added more flags to open so it
can test most open system call invocations of interest) in:
https://github.com/nfs-ganesha/nfs-ganesha/tree/next/src/tools/multilock
Hmm, I should incorporate the features of Bruce's lock tests into that...
The multilock tool can drive multiple clients to use system calls (so any
POSIX client can be used including a local process on the server) or
Gluster's libgfapi or Cephs libcephfs.
Frank
 -----Original Message-----
 From: J. Bruce Fields [mailto:bfields@fieldses.org]
 Sent: Friday, January 7, 2022 1:35 PM
 To: Chuck Lever <chuck.lever(a)oracle.com>
 Cc: linux-nfs(a)vger.kernel.org
 Subject: NFS testing
 
 Chuck was asking about the regular NFS testing I do.  Cc'ing the list in 
case
this is
 useful to anyone else.
 
 We'd really like to set up regular testing on some kind of common
infrastructure
 that more people can get to.  I'm not sure how to get there yet.
 
 For now all I have is this pile of bash scripts that build kernels and 
boot test
VMs
 and run tests between them, all on a machine in my
 basement:
 
 	
http://git.linux-nfs.org/?p=bfields/testd.git;a=tree
 
 The "install.sh" file has notes on my setup.
 
 The thing I run most regularly is this:
 
 	
http://git.linux-nfs.org/?p=bfields/testd.git;a=blob;f=bin/do-all
 
 which runs:
 
 	- connectathon, on v3, v4, v4.1, and v4.2, each with both
 	  auth_sys and krb5.  Except v4.2, which I run with auth_sys,
 	  krb5i, and krb5p.
 	- at the same time as connectathon (so with the same
 	  permutations as the above), I also run the tests in
 
 		
http://git.linux-nfs.org/?p=bfields/lock-tests.git
 
 	  which check basic lock and lease functionality plus some odd
 	  corner cases I ran into some years ago.
 	- pynfs 4.0 tests:
 
 pynfs
 	  I do two auth_sys runs, one as root, one not.  (Tests that
 	  create special files need root, tests that expect permission
 	  failures need non-root).  A couple krb5 runs are temporarily
 	  disabled.
 
 	  My goal is that a normal result should be "everything passed",
 	  so that it stands out when there's a regression.  So I skip a
 	  few known failures:
 		
http://git.linux-
 nfs.org/?p=bfields/testd.git;a=blob;f=data/pynfs-skip
 	- pynfs 4.1 tests: similar if a little less complicated:
 
 xfstests
 	  This is the most time-consuming, so I just do a single run
 	  over NFSv4.2 with auth_sys.
 
 	  As with pynfs I aim for the normal result to be "everything
 	  passed", so I skip these known failures:
 		
http://git.linux-
 nfs.org/?p=bfields/testd.git;a=blob;f=data/xfstests-failed
 	  I also normally skip anything that takes more than a couple
 	  minutes, unfortunately:
 		
http://git.linux-
 nfs.org/?p=bfields/testd.git;a=blob;f=data/xfstests-slow
 
 I also have some other test sets in there that I don't use as often.
 And I "bisect" script that will run other tests, e.g.
 
 	qtst <host> bisect <good> <bad> xfstests generic/465
 
 and it'll crank away for a few hours and (hopefully) mail me a git-bisect
result
 telling me where generic/465 started failing.
 
 --b.