btrfs/016: fix a false alert due to xattrs mismatch [BUG] When running btrfs/016 after any other test case, it would fail on a SELinux enabled environment: btrfs/015 1s ... 0s btrfs/016 1s ... [failed, exit status 1]- output mismatch (see ~/xfstests-dev/results//btrfs/016.out.bad) --- tests/btrfs/016.out 2023-12-28 10:39:36.481027970 +1030 +++ ~/xfstests-dev/results//btrfs/016.out.bad 2023-12-28 15:53:10.745436664 +1030 @@ -1,2 +1,3 @@ QA output created by 016 -Silence is golden +fssum failed +(see ~/xfstests-dev/results//btrfs/016.full for details) ... (Run 'diff -u ~/xfstests-dev/tests/btrfs/016.out ~/xfstests-dev/results//btrfs/016.out.bad' to see the entire diff) Ran: btrfs/015 btrfs/016 Failures: btrfs/016 Failed 1 of 2 tests [CAUSE] The test case itself would try to use a blank SELinux context for the SCRATCH_MNT, to control the xattrs. But the initial send stream is generated from $TEST_DIR, which may still have the default SELinux mount context. And such mismatch in the SELinux xattr (source on $TEST_DIR still has the extra xattr, meanwhile the receve end on $SCRATCH_MNT doesn't) would lead to above mismatch. [FIX] Fix the false alerts by disable XATTR checks. Furthermore instead of doing all the edge juggling using $TEST_DIR, this time we do all the work on $SCRATCH_MNT. This means we would generate the initial send stream from $SCRATCH_MNT, then reformat the fs, mount scratch again, receive and verify. We no longer needs to cleanup the extra file for the initial send stream, as they are on the scratch device and would be formatted anyway. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
common/config: fix CANON_DEVS=yes when file does not exist CANON_DEVS=yes allows you to use symlinks for devices, so fstests resolves them back to the real backing device. The iteration for resolving the backing device works obviously if you have the file present, but if one was not present there is a parsing error. Fix this parsing error introduced by a0c36009103b8 ("fstests: add helper to canonicalize devices used to enable persistent disks"). Fixes: a0c36009103b8 ("fstests: add helper to canonicalize devices used to enable persistent disks" Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/736: fix a buffer overflow in readdir-while-renames.c The test is using a 32 characters buffer to print the full path for each file name, which in some setups it's not enough because $TEST_DIR can point to a path name longer than that, or even smaller but then the buffer is still not large enough after appending a file name. When that's the case it results in a core dump like this: generic/736 QA output created by 736 *** buffer overflow detected ***: terminated /opt/xfstests/tests/generic/736: line 32: 9217 Aborted (core dumped) $here/src/readdir-while-renames $target_dir Silence is golden - output mismatch (see /opt/xfstests/results//generic/736.out.bad) --- tests/generic/736.out 2024-01-14 12:01:35.000000000 -0500 +++ /opt/xfstests/results//generic/736.out.bad 2024-01-23 18:58:37.990000000 -0500 @@ -1,2 +1,4 @@ QA output created by 736 +*** buffer overflow detected ***: terminated +/opt/xfstests/tests/generic/736: line 32: 9217 Aborted (core dumped) $here/src/readdir-while-renames $target_dir Silence is golden ... (Run diff -u /opt/xfstests/tests/generic/736.out /opt/xfstests/results//generic/736.out.bad to see the entire diff) Ran: generic/736 Failures: generic/736 Failed 1 of 1 tests We don't actually need to print the full path into the buffer, because we have previously set the current directory (chdir) to the path pointed by "dir_path". So fix this by printing only the relative path name which uses at most 5 characters (NUM_FILES is 5000 plus the nul terminator). Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
tests/*/Makefile: make sure group.list DIRT exists before install * sometimes make install was failing with: cp: cannot stat 'group.list': No such file or directory and bunch of non-fatal messages: mv: failed to preserve ownership for 'group.list': Invalid argument * this was when tools/mkgroupfile did mv -f "$new_groups" "$groupfile" overwritting the group.list file while install-sh was already copying it to output * in the end easily reproducible by 1) removing tests/*/group.list before each make install 2) adding some sleep in mkgroupfile before the mv call Signed-off-by: Martin Jansa <martin.jansa@gmail.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs: require no nodatacow for tests that exercise read repair Several test cases that exercise the ability to detect corrupted data and repair it, fail when "-o nodatacow" is passed to MOUNT_OPTIONS, because that ability requires the existence of data checksums, and those are disabled in nodatacow mode. So skip the tests when "-o nodatacow" is present. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/299: skip test if we were mounted with nodatacow The test requires the ability to create an inline extent in a file with a prealloced extent, created with fallocate's FALLOC_FL_KEEP_SIZE mode, which can only happen when COW is enabled. If the test is run with MOUNT_OPTIONS="-o nodatacow", then COW never happens as all writes end up using the preallocated extent. This results in the logical-resolve command to return one file path when it should return none, since the base logical address of the prealloc extent is still in use unless COW happens. So make the test not run if nodatacow is specified in MOUNT_OPTIONS. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs/173: make the test work when mounting with nodatacow Currently btrfs/173 fails when passing "-o nodatacow" to MOUNT_OPTIONS because it assumes that when creating a file it does not have the nodatacow flag set, which is obviously not true if the fs is mounted with "-o nodatacow". To allow the test to run successfully with nodatacow, just make sure it clears the nodatacow flag from the file if the fs was mounted with "-o nodatacow". Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs: require no nodatacow for tests that exercise compression Several test cases fail when running with MOUNT_OPTIONS="-o nodatacow" because they attempt to use compression and compression can not be enabled on nodatacow files (it fails with -EINVAL). So make sure those tests are not run if nodatacow is specified in MOUNT_OPTIONS. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/682: update and fix-up golden output coreutils v9.4 introduced a change in the error output of mv under certain errno values via commit 3cb862ce5f10 ("mv: better diagnostic for 'mv dir x' failure"), which broke the golden output. Update golden output to match the change, and further add an output filter to avoid having the test fail on environments that ran with an older coreutils release, taken from commit d9323ad7a05e ("generic/245: Filter mv error message"). Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic/68[12]: use the dir blocksize for xfs filesystems The tests are using the filesystem block size for calculating the number of dirents required to fill a 2-block directory. For v4 xfs filesystems formatted with fs blocksize of 512 bytes this is failing, as the tests do not take into account that the directory block size is not always equal to the filesystem block size. As such, the tests never go over quota, and even if they did there is no hard block limit being set (due to 512 / 1024 = 0 calculation in setquota). Use the directory blocksize instead of the filesystem blocksize, when the fstype under test is xfs. Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs: check conversion of zoned fileystems Recently we had a bug where a zoned filesystem could be converted to a higher data redundancy profile than supported. Add a test-case to check the conversion on zoned filesystems. Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
btrfs: detect regular qgroup for older kernels correctly [BUG] When running an older (vendoer v6.4) kernel, some qgroup test cases would be skipped: btrfs/017 1s ... [not run] not running normal qgroups [CAUSE] With the introduce of simple quota mode, there is a new sysfs interface, /sys/fs/btrfs/<uuid>/qgroups/mode to indicate the currently running qgroup modes. And _qgroup_mode() from `common/btrfs` is using that new interface to detect the mode. Unfortuantely for older kernels without simple quota support, _qgroup_mode() would return "disabled" directly, causing those test case to be skipped. [FIX] Fallback to regular qgroup if that sysfs interface is not accessible, as qgroup is introduced from the very beginning of btrfs, thus the regular qgroup is always supported. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
btrfs: btrfs/224 do not assign snapshot to a subvolume qgroup For "btrfs subvolume snapshot -i <qgroupid>", we only expect the target qgroup to be a higher level one. Assigning a 0 level qgroup to another 0 level qgroup is only going to cause confusion, and I'm planning to do extra sanity checks both in kernel and btrfs-progs to reject such behavior. So change the test case to do regular higher level qgroup assignment only. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
btrfs: validate inconsitent qgroup won't leak reserved data space There is a kernel regression caused by commit e15e9f43c7ca ("btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting"), where if qgroup is inconsistent (not that hard to trigger) btrfs would leak its qgroup data reserved space, and cause a warning at unmount time. The test case would verify the behavior by: - Enable qgroup first - Intentionally mark qgroup inconsistent This is done by taking a snapshot and assign it to a higher level qgroup, meanwhile the source has no higher level qgroup. - Trigger a large enough write to cause qgroup data space leak - Unmount and check the dmesg for the qgroup rsv leak warning Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
btrfs: test tempfsid with device add, seed, and balance Make sure that basic functions such as seeding and device add fail, while balance runs successfully with tempfsid. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
btrfs: validate send-receive operation with tempfsid. Given concurrent mounting of both the original and its clone device on the same system, this test confirms the integrity of send and receive operations in the presence of active tempfsid. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>