On Wed, Sep 1, 2021 at 7:43 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Wed, Sep 01, 2021 at 07:46:01AM +0300, Amir Goldstein wrote: > > On Wed, Sep 1, 2021 at 3:37 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > Create a file to document the purpose of each test group that is > > > currently defined in fstests, and add a build script to check that every > > > group mentioned in the tests is also mentioned in the documentation. > > > > > > > This is awesome and long due. > > Thanks for doing that! > > > > Minor nits about overlayfs groups below... > > Heh, yeah, thanks for making corrections. :) > > > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > --- > > > doc/group-names.txt | 136 ++++++++++++++++++++++++++++++++++++++++++++++++ > > > include/buildgrouplist | 1 > > > tools/check-groups | 33 ++++++++++++ > > > 3 files changed, 170 insertions(+) > > > create mode 100644 doc/group-names.txt > > > create mode 100755 tools/check-groups > > > > > > > > > diff --git a/doc/group-names.txt b/doc/group-names.txt > > > new file mode 100644 > > > index 00000000..ae517328 > > > --- /dev/null > > > +++ b/doc/group-names.txt > > > @@ -0,0 +1,136 @@ > > > +======================= ======================================================= > > > +Group Name: Description: > > > +======================= ======================================================= > > > +all All known tests, automatically generated by ./check at > > > + runtime > > > +auto Tests that should be run automatically. These should > > > + not require more than ~5 minutes to run. > > > +quick Tests that should run in under 30 seconds. > > > +deprecated Old tests that should not be run. > > > + > > > +acl Access Control Lists > > > +admin xfs_admin functionality > > > +aio general libaio async io tests > > > +atime file access time > > > +attr extended attributes > > > +attr2 xfs v2 extended aributes > > > +balance btrfs tree rebalance > > > +bigtime timestamps beyond the year 2038 > > > +blockdev block device functionality > > > +broken broken tests > > > +cap Linux capabilities > > > +casefold directory name casefolding > > > +ci ASCII case-insensitive directory name lookups > > > +clone FICLONE/FICLONERANGE ioctls > > > +clone_stress stress testing FICLONE/FICLONERANGE > > > +collapse fallocate collapse_range > > > +compress file compression > > > +convert btrfs ext[34] conversion tool > > > +copy xfs_copy functionality > > > +copy_range copy_file_range syscall > > > +copyup overlayfs copyup support > > > > The tests in this group exercise copy up. > > There is no such thing as overlayfs without "copyup support", > > so guess my point is - remove the word "support" > > OK. > > > > +dangerous dangerous test that can crash the system > > > +dangerous_bothrepair fuzzers to evaluate xfs_scrub + xfs_repair repair > > > +dangerous_fuzzers fuzzers that can crash your computer > > > +dangerous_norepair fuzzers to evaluate kernel metadata verifiers > > > +dangerous_online_repair fuzzers to evaluate xfs_scrub online repair > > > +dangerous_repair fuzzers to evaluate xfs_repair offline repair > > > +dangerous_scrub fuzzers to evaluate xfs_scrub checking > > > +data data loss checkers > > > +dax direct access mode for persistent memory files > > > +db xfs_db functional tests > > > +dedupe FIEDEDUPERANGE ioctl > > > +defrag filesystem defragmenters > > > +dir directory test functions > > > +dump dump and restore utilities > > > +eio IO error reporting > > > +encrypt encrypted file contents > > > +enospc ENOSPC error reporting > > > +exportfs file handles > > > +filestreams XFS filestreams allocator > > > +freeze filesystem freeze tests > > > +fsck general fsck tests > > > +fsmap FS_IOC_GETFSMAP ioctl > > > +fsr XFS free space reorganizer > > > +fuzzers filesystem fuzz tests > > > +growfs increasing the size of a filesystem > > > +hardlink hardlinks > > > +health XFS health reporting > > > +idmapped idmapped mount functionality > > > +inobtcount XFS inode btree count tests > > > +insert fallocate insert_range > > > +ioctl general ioctl tests > > > +io_uring general io_uring async io tests > > > +label filesystem labelling > > > +limit resource limits > > > +locks file locking > > > +log metadata logging > > > +logprint xfs_logprint functional tests > > > +long_rw long-soak read write IO path exercisers > > > +metacopy overlayfs metadata-only copy-up > > > +metadata filesystem metadata update exercisers > > > +metadump xfs_metadump/xfs_mdrestore functionality > > > +mkfs filesystem formatting tools > > > +mount mount option and functionality checks > > > +nested nested overlayfs instances > > > +nfs4_acl NFSv4 access control lists > > > +nonsamefs overlayfs layers on different filesystems > > > +online_repair online repair functionality tests > > > +other dumping ground, do not add more tests to this group > > > +overlay using overlayfs on top of FSTYP > > > > This description is a bit confusing, because the recommended > > way to run overlayfs tests as described in README.overlay is > > to set FSTYP=xfs and run ./check -overlay > > > > I'm struggling for a better description but perhaps: > > "using overlayfs regardless of ./check -overlay flag"? > > Hmm. Since I'm the author of the only test that uses this tag, I guess > I'm the authority (ha!) on what the name actually means. > > That test (generic/631) is a regression test for a XFS whiteout handling > bug that can only be reproduced by layering overlayfs atop xfs. > Overlayfs is incidental to reproducing the XFS bug, but AFAIK overlayfs > is the only in-kernel user of whiteout, which is why it's critical here. > > It's not right to make it "_supported_fs overlay" because we're not > testing overlayfs functionality; we're merely using it as a stick to > poke another filesystem. Yes. I know. Note that while this is the only case of _require_extra_fs overaly there is another case of _require_extra_fs ext2 (xfs/049) > > How about: "regression tests that require the use of overlayfs in a > targetted configuration" ? > TBH, I do not think it is wise to tag the test by the test method rather than the tested functionality. What is more likely? that a tester wants to run all tests that use overlay over FSTYP? Or that a tester wants to run all tests to verify whiteout related behavior after changing whiteout related code? I suggest that you re-tag this test as 'whiteout', which is documented already. If you want to be more specific, you can create a group rename_whiteout, because RENAME_WHITEOUT is the vfs interface that this test is actually exercising. Thanks, Amir.
