Filipe Manana [Wed, 6 Mar 2024 15:01:57 +0000 (15:01 +0000)]
btrfs: fix grep warning at _require_btrfs_mkfs_uuid_option()
When running _require_btrfs_mkfs_uuid_option(), some grep versions
complain about escaping the dash characters and make the tests that
use this function fail like this:
btrfs/313 2s - output mismatch (see /root/fstests/results//btrfs_normal/btrfs/313.out.bad)
--- tests/btrfs/313.out 2024-03-05 18:48:34.929372495 +0000
+++ /root/fstests/results//btrfs_normal/btrfs/313.out.bad 2024-03-05 20:52:27.745166101 +0000
@@ -1,5 +1,8 @@
QA output created by 313
---- clone_uuids_verify_tempfsid ----
+grep: warning: stray \ before -
+grep: warning: stray \ before -
+grep: warning: stray \ before -
Mounting original device
On disk fsid: FSID
...
(Run 'diff -u /root/fstests/tests/btrfs/313.out /root/fstests/results//btrfs_normal/btrfs/313.out.bad' to see the entire diff)
btrfs/314 3s - output mismatch (see /root/fstests/results//btrfs_normal/btrfs/314.out.bad)
--- tests/btrfs/314.out 2024-03-05 18:48:34.929372495 +0000
+++ /root/fstests/results//btrfs_normal/btrfs/314.out.bad 2024-03-05 20:52:32.880237216 +0000
@@ -1,6 +1,9 @@
QA output created by 314
From non-tempfsid SCRATCH_MNT to tempfsid TEST_DIR/314/tempfsid_mnt
+grep: warning: stray \ before -
+grep: warning: stray \ before -
+grep: warning: stray \ before -
wrote 9000/9000 bytes at offset 0
...
So fix this by not escaping anymore the dashes and using the -- separator
before the regex pattern parameter.
Reviewed-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
Qu Wenruo [Mon, 19 Feb 2024 08:00:07 +0000 (18:30 +1030)]
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>
Luis Chamberlain [Wed, 14 Feb 2024 17:42:08 +0000 (09:42 -0800)]
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>
Filipe Manana [Sun, 11 Feb 2024 11:28:26 +0000 (11:28 +0000)]
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>
Martin Jansa [Thu, 8 Feb 2024 22:52:41 +0000 (23:52 +0100)]
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>
Filipe Manana [Thu, 1 Feb 2024 18:03:50 +0000 (18:03 +0000)]
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>
Filipe Manana [Thu, 1 Feb 2024 18:03:49 +0000 (18:03 +0000)]
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>
Filipe Manana [Thu, 1 Feb 2024 18:03:48 +0000 (18:03 +0000)]
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>
Filipe Manana [Thu, 1 Feb 2024 18:03:47 +0000 (18:03 +0000)]
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>
Anthony Iliopoulos [Thu, 1 Feb 2024 16:17:32 +0000 (17:17 +0100)]
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>
Anthony Iliopoulos [Thu, 1 Feb 2024 16:17:31 +0000 (17:17 +0100)]
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>
Qu Wenruo [Tue, 20 Feb 2024 04:01:34 +0000 (14:31 +1030)]
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.
Qu Wenruo [Mon, 26 Feb 2024 04:02:34 +0000 (14:32 +1030)]
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.
Qu Wenruo [Fri, 23 Feb 2024 09:35:47 +0000 (20:05 +1030)]
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
Anand Jain [Mon, 19 Feb 2024 19:48:49 +0000 (03:48 +0800)]
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>
Anand Jain [Mon, 19 Feb 2024 19:48:46 +0000 (03:48 +0800)]
btrfs: test case prerequisite _require_btrfs_mkfs_uuid_option
For easier and more effective testing of btrfs tempfsid, newer versions
of mkfs.btrfs contain options such as --device-uuid. Check if the
currently running mkfs.btrfs contains this option.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
Anand Jain [Mon, 19 Feb 2024 19:48:44 +0000 (03:48 +0800)]
btrfs: verify that subvolume mounts are unaffected by tempfsid
The tempfsid logic must determine whether the incoming mount request
is for a device already mounted or a new device mount. Verify that it
recognizes the device already mounted well by creating reflink across
the subvolume mount points.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
Anand Jain [Mon, 19 Feb 2024 19:48:42 +0000 (03:48 +0800)]
btrfs: introduce tempfsid test group
Introducing a new test group named tempfsid.
Tempfsid is a feature of the Btrfs filesystem. When encountering another
device with the same fsid as one already mounted, the system will mount
the new device with a temporary, randomly generated in-memory fsid.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
Anand Jain [Mon, 19 Feb 2024 19:48:41 +0000 (03:48 +0800)]
common/rc: assign SCRATCH_DEV_POOL to an array
Many test cases use local variables to manage the names of each device in
SCRATCH_DEV_POOL. Let _scratch_dev_pool_get set an array, SCRATCH_DEV_NAME,
for it.
Usage:
_scratch_dev_pool_get <n>
# device names are in the array SCRATCH_DEV_NAME.
${SCRATCH_DEV_NAME[0]} ${SCRATCH_DEV_NAME[1]} ...
_scratch_dev_pool_put
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Mon, 19 Feb 2024 12:01:30 +0000 (12:01 +0000)]
btrfs: test incremental send on sparse file with trailing hole
Test that an incremental send does not issue unnecessary writes for a
sparse file that got one new extent between its previous extent and the
file's size.
This exercises a fix by the following patch:
"btrfs: send: don't issue unnecessary zero writes for trailing hole"
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Anand Jain <anand.jain@oracle.com>
Darrick J. Wong [Wed, 7 Feb 2024 02:19:30 +0000 (18:19 -0800)]
xfs/122: fix for xfs_attr_shortform removal in 6.8
The xfs_attr_shortform struct (with multiple flexarrays) was removed in
6.8. Check the two surviving structures (the attr sf header and entry)
instead.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 7 Feb 2024 02:19:25 +0000 (18:19 -0800)]
common/xfs: only pass -l in _xfs_mdrestore for v2 metadumps
fstests has a weird history with external log devices -- prior to the
introduction of metadump v2, a dump/restore cycle would leave an
external log unaltered, and most tests worked just fine. Were those
tests ignorant? Or did they pass intentionally?
Either way, we don't want to pass -l to xfs_mdrestore just because we
have an external log, because that switch is new and causes regressions
when testing with xfsprogs from before 6.5.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 7 Feb 2024 02:19:19 +0000 (18:19 -0800)]
xfs/503: split copy and metadump into two tests
This test examines the behavior of xfs_copy and xfs_metadump. Metadump
now supports capturing external log contents, but copy does not. Split
the test into two to improve coverage on multidevice filesystems.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 7 Feb 2024 02:19:08 +0000 (18:19 -0800)]
xfs/{129,234,253,605}: disable metadump v1 testing with external devices
The metadump v1 format does not support capturing content from log
devices or realtime devices. Hence it does not make sense to test these
scenarios. Create predicates to decide if we want to test a particular
metadump format, then convert existing tests to check formats
explicitly.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 7 Feb 2024 02:19:02 +0000 (18:19 -0800)]
common: refactor metadump v1 and v2 tests, version 2
Refactor the copy-pasta'd code in xfs/129, xfs/234, xfs/253, xfs/291,
xfs/432, xfs/503, and xfs/605 so that we don't have to maintain nearly
duplicate copies of the same code.
While we're at it, fix the fsck so that it includes xfs_scrub.
[v2]
After the first version of this patch was committed to fstests for-next,
Zorro reported that the cleanup function in common/xfs_metadump_tests
zapped one of his test machines because of a well known shell variable
expansion + globbing footgun. This can trigger when running fstests on
older configurations where a test adds _cleanup_verify_metadump to the
local _cleanup function but exits before calling _setup_verify_metadump
to set XFS_METADUMP_IMG to a non-empty value.
Redesign the cleanup function to check for non-empty values of
XFS_METADUMP_{FILE,IMG} before proceeding with the rm. Change the
globbed parameter of "rm -f $XFS_METADUMP_IMG*" to a for loop so that if
the glob does not match any files, the loop variable will be set to a
path that does not resolve anywhere.
The for-next branch was reverted to v2024.01.14, hence this patch is
being resubmitted with the fix inline instead of as a separate fix
patch.
Longer term maybe we ought to set -u or something. Or figure out how to
make the root directory readonly.
Darrick J. Wong [Wed, 7 Feb 2024 02:18:56 +0000 (18:18 -0800)]
xfs/336: fix omitted -a and -o in metadump call
Commit e443cadcea reworked _xfs_metadump to require that all callers
always pass the arguments they want -- no more defaulting to "-a -o".
Unfortunately, a few got missed. Fix some of them now; the rest will
get cleaned up in the next patch.
Fixes: e443cadcea ("common/xfs: Do not append -a and -o options to metadump") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 7 Feb 2024 02:18:51 +0000 (18:18 -0800)]
common/populate: always metadump full metadata blocks
Commit e443cadcea pushed the -a and -o options to the
_scratch_xfs_metadump callsites. Unfortunately, it missed the
_xfs_metadump callsite in common/populate, so fix that now.
Fixes: e443cadcea ("common/xfs: Do not append -a and -o options to metadump") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 7 Feb 2024 02:18:45 +0000 (18:18 -0800)]
common/xfs: simplify maximum metadump format detection
xfs_metadump (aka the wrapper around xfs_db -c metadump) advertises the
-v switch to turn on v2 format in its help screen. There's no need to
fire up xfs_db on the scratch device which will load the AGs and take
much longer.
While we're at it, reduce the amount of boilerplate in the test files by
changing the function to emit the max version supported.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 7 Feb 2024 02:18:39 +0000 (18:18 -0800)]
generic/256: constrain runtime with TIME_FACTOR
This test runs 500 iterations of a "fill the fs and try to punch" test.
Hole punching can be particularly slow if, say, the filesystem is
mounted with -odiscard and the DISCARD operation takes a very long time.
In extreme cases, I can see test runtimes of 4+ hours.
Constrain the runtime of _test_full_fs_punch by establishing a deadline
of (30 seconds * TIME_FACTOR) and breaking out of the for loop if the
test goes beyond the time budget. This keeps the runtime within the
customary 30 seconds.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Sat, 3 Feb 2024 08:12:28 +0000 (10:12 +0200)]
overlay/084: Fix test to match new xwhiteouts dir on-disk format
The xwhiteouts feature, which is tested in this test, was added to
overlayfs in kernel v6.7.
The on-disk format of the xwhiteouts directory was changed in kernel
v6.8-rc2, specfically by commit 420332b94119 ("ovl: mark xwhiteouts
directory with overlay.opaque='x'") and backported to kernel v6.7.3,
so this test now fails on kernel >= v6.8-rc2 and => v6.7.3.
Adapt the test to the new on-disk format and add a hint to make sure
that the on-disk format change is backported to v6.7 based kernels.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Alexander Larsson <alexl@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yang Xu [Thu, 1 Feb 2024 04:23:48 +0000 (23:23 -0500)]
t_snapshot_deleted_subvolume: add check for BTRFS_IOC_SNAP_DESTROY_V2
On some platform, struct btrfs_ioctl_vol_args_v2 is defined, but the
macros BTRFS_IOC_SNAP_DESTROY_V2 is not defined. This will cause
compile error. Add check for BTRFS_IOC_SNAP_DESTROY_V2 to solve this
problem.
BTRFS_IOC_SNAP_CREATE_V2 and BTRFS_IOC_SUBVOL_CREATE_V2 were
introduced together with struct btrfs_ioctl_vol_args_v2 by the
commit 55e301fd57a6 ("Btrfs: move fs/btrfs/ioctl.h to
include/uapi/linux/btrfs.h"). So there is no need to check them.
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Tue, 23 Jan 2024 19:56:59 +0000 (11:56 -0800)]
btrfs: Remove btrfs/303
This test was reproducing a bug triggered by creating a subvolume qgroup
before creating the subvolume itself with a snapshot.
The kernel patch:
btrfs: forbid creating subvol qgroups
explicitly prevents that and makes it fail with EINVAL. I could "fix"
this test by expecting the EINVAL message in the output, but at that
point it would simply be a test that creating a subvolume and
snapshotting it works with qgroups, which is adequately tested by other
tests which focus on accurately measuring shared/exclusive usage in
various snapshot/reflink scenarios. To avoid confusion, I think it is
best to simply delete this test.
Signed-off-by: Boris Burkov Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Richard Weinberger [Sun, 14 Jan 2024 13:57:13 +0000 (14:57 +0100)]
generic/020: Compute correct max_attrs for UBIFS
When testing on a MTD with a rather small erase block
size, the default max_attr limit can be too much and the
test will fail.
Instead compute the actual limit.
Signed-off-by: Richard Weinberger <richard@nod.at> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs/604: Make test as _notrun for higher blocksizes filesystem
If we have filesystem with blocksize = 64k, then the falloc value will
be huge (falloc_size=5451.33GB) which makes fallocate fail hence causing
the test to fail. Instead make the testcase "_notrun" if the initial
fallocate itself fails.
Signed-off-by: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Sat, 27 Jan 2024 20:44:17 +0000 (07:14 +1030)]
btrfs: verify the read behavior of compressed inline extent
[BUG]
There is a report about reading a zstd compressed inline file extent
would lead to either a VM_BUG_ON() crash, or lead to incorrect file
content.
[CAUSE]
The root cause is a incorrect memcpy_to_page() call, which uses
incorrect page offset, and can lead to either the VM_BUG_ON() as we may
write beyond the page boundary, or writes into the incorrect offset of
the page.
[TEST CASE]
The test case would:
- Mount with the specified compress algorithm
- Create a 4K file
- Verify the 4K file is all inlined and compressed
- Verify the content of the initial write
- Cycle mount to drop all the page cache
- Verify the content of the file again
- Unmount and fsck the fs
This workload would be applied to all supported compression algorithms.
And it can catch the problem correctly by triggering VM_BUG_ON(), as our
workload would result decompressed extent size to be 4K, and would
trigger the VM_BUG_ON() 100%.
And with the revert or the new fix, the test case can pass safely.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Zorro Lang [Sun, 28 Jan 2024 15:56:53 +0000 (23:56 +0800)]
xfs: test xfs_growfs with too-small size expansion
This's a regression test of 84712492e6da ("xfs: short circuit
xfs_growfs_data_private() if delta is zero").
If try to do growfs with "too-small" size expansion, might lead to a
delta of "0" in xfs_growfs_data_private(), then end up in the shrink
case and emit the EXPERIMENTAL warning even if we're not changing
anything at all.
Signed-off-by: Zorro Lang <zlang@redhat.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Pavel Reichl [Wed, 6 Dec 2023 07:15:25 +0000 (08:15 +0100)]
xfs/598: Add missing "fixed_by" hints
Kernel patches, the very same as for xfs/597, are necessary for scrub
to function as expected.
_check_xfs_filesystem: filesystem on /dev/sda3 failed scrub
xfs_scrub -v -d -n output ***
EXPERIMENTAL xfs_scrub program in use! Use at your own risk!
Phase 1: Find filesystem geometry.
/mnt/scratch: using 2 threads to scrub.
Phase 2: Check internal metadata.
Info: AG 1 superblock: Optimization is possible. (scrub.c line 212)
Info: AG 2 superblock: Optimization is possible. (scrub.c line 212)
Info: AG 3 superblock: Optimization is possible. (scrub.c line 212)
Phase 3: Scan all inodes.
Corruption: inode 131 (0/131) directory entries: Repairs are required. (scrub.c line 196)
Phase 5: Check directory tree.
Info: /mnt/scratch: Filesystem has errors, skipping connectivity checks. (phase5.c line 392)
Phase 7: Check summary counters.
203.0MiB data used; 5 inodes used.
64.2MiB data found; 5 inodes found.
5 inodes counted; 5 inodes checked.
/mnt/scratch: corruptions found: 1
/mnt/scratch: Re-run xfs_scrub without -n.
end xfs_scrub output
mount output ***
Signed-off-by: Pavel Reichl <preichl@redhat.com> Reviewed-by: Bill O'Donnell <bodonnel@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Su Yue [Mon, 29 Jan 2024 23:51:04 +0000 (07:51 +0800)]
common/rc: improve block_size support for bcachefs
mkfs.bcachefs now supports option '--block_size' to allow
custom block_size.
Add the pattern to set def_blksz if MKFS_OPTIONS contains the
option in _scratch_mkfs_sized.
Also let mkfs.bcachefs decide blocksize if no option is given in
MKFS_OPTIONS or _scratch_mkfs_sized parameter.
Signed-off-by: Su Yue <glass.su@suse.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Su Yue [Mon, 29 Jan 2024 23:51:03 +0000 (07:51 +0800)]
fstests: introduce MKFS_BCACHEFS_PROG for bcachefs
mkfs.bcachefs supports force overwrite when option '-f' is given:
$ mkfs.bcachefs --help | grep force
-f, --force
There are some tests which call _scratch_mkfs multiple times
e.g. tests/generic/171. Without '-f' in MKFS_OPTIONS,
these tests just hang in overwrite confirmation.
After this commit, MKFS_BCACHEFS_PROG will contains ' -f' so
we don't have to add '-f' to MKFS_OPTIONS manually to make
these tests pass.
It also fixes generic/466 which unsets MKFS_OPTIONS causing
that test hangs in mfks.bcachefs waiting for confirmation of
the force overwrite.
Signed-off-by: Su Yue <glass.su@suse.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Tue, 21 Nov 2023 22:39:09 +0000 (14:39 -0800)]
generic: add test for custom crypto data unit size
Add a test that verifies the on-disk format of encrypted files that use
a crypto data unit size that differs from the filesystem block size.
This tests the functionality that was introduced in Linux 6.7 by kernel
commit 5b1188847180 ("fscrypt: support crypto data unit size less than
filesystem block size").
This depends on the xfsprogs patch
"xfs_io/encrypt: support specifying crypto data unit size"
(https://lore.kernel.org/r/20231013062639.141468-1-ebiggers@kernel.org)
which adds the '-s' option to the set_encpolicy command of xfs_io.
As usual, the test skips itself when any prerequisite isn't met.
[zlang: add _wants_kernel_commit]
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Tue, 21 Nov 2023 22:39:08 +0000 (14:39 -0800)]
common/encrypt: support custom data unit size
Make _require_scratch_encryption() and
_require_encryption_policy_support() support the new '-s' option to
set_encpolicy to specify a custom value of log2_data_unit_size.
Likewise, make _verify_ciphertext_for_encryption_policy() accept an
argument "log2_dusize=*" to cause it to use the specified data unit size
for the test and verify that the file contents are encrypted as expected
for that data unit size.
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Tue, 21 Nov 2023 22:39:06 +0000 (14:39 -0800)]
fscrypt-crypt-util: rename block to data unit
Rename the --block-size option to --data-unit-size, and rename the
--block-number option to --data-unit-index.
This does not change any functionality, but this avoids confusion now
that the kernel supports the case where the crypto data unit size is not
the same as the filesystem block size. fscrypt-crypt-util cares about
the crypto data unit size, not the filesystem block size.
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Omar Sandoval [Tue, 19 Dec 2023 18:34:37 +0000 (10:34 -0800)]
btrfs: test snapshotting a deleted subvolume
This is a regression test for patch "btrfs: don't abort filesystem when
attempting to snapshot deleted subvolume". Without the fix, the
filesystem goes read-only and prints a warning. With the fix, it should
fail gracefully with ENOENT.
Johannes Thumshirn [Wed, 13 Dec 2023 11:35:30 +0000 (03:35 -0800)]
btrfs: add fstest for overwriting a file partially with RST
Add a test writing 128k to an empty file with one stripe already
pre-filled on-disk. Then overwrite a portion of the file in the middle.
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>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
Johannes Thumshirn [Wed, 13 Dec 2023 11:35:29 +0000 (03:35 -0800)]
btrfs: add fstests to write 128k to a RST filesystem
Add a test writing 128k to a file on an empty filesystem formatted with a
raid-stripe-tree.
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>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
Johannes Thumshirn [Wed, 13 Dec 2023 11:35:28 +0000 (03:35 -0800)]
btrfs: add fstest for writing to a file at an offset with RST
Add a fstest writing 4k at offset 64k to a file with one RAID tripe
already pre-filled for a raid-stripe-tree formatted file system.
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>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
Johannes Thumshirn [Wed, 13 Dec 2023 11:35:27 +0000 (03:35 -0800)]
btrfs: add fstest for 8k write spanning two stripes on raid-stripe-tree
Add a test-case writing 8k to a raid-stripe-tree formatted filesystem with
one stripe pre-filled to 60k so the 8k are split into a 4k write finishing
stripe 1 and a 4k write starting the next stripe.
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>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
Johannes Thumshirn [Wed, 13 Dec 2023 11:35:26 +0000 (03:35 -0800)]
btrfs: add fstest for stripe-tree metadata with 4k write
Test a simple 4k write on all RAID profiles currently supported with the
raid-stripe-tree.
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>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
Johannes Thumshirn [Wed, 13 Dec 2023 11:35:23 +0000 (03:35 -0800)]
common: add filter for btrfs raid-stripe dump
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>
[ add trailing whitespace and the version filter ] Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Fri, 29 Dec 2023 06:27:39 +0000 (14:27 +0800)]
common: add _filter_trailing_whitespace
The command 'btrfs inspect-internal dump-tree -t raid_stripe'
introduces trailing whitespace in its output.
Apply a filter to remove it. Used in btrfs/30[4-8][.out].
Signed-off-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
The new overlayfs mount options lowerdir+,datadir+ don't fit well
into any of the existing _overlay_scratch_mount* helpers.
Add this new helper to reduce a common pattern of custom mount options.
Suggested-by: Zorro Lang <zlang@kernel.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 10 Jan 2024 18:27:28 +0000 (13:27 -0500)]
generic/732: don't run it on NFS
This test sets up two independent superblocks with the same backend
server, and then does RENAMES of the same files in the two servers. This
is basically trying to simulate the case where two clients are competing
to rename files in the same directory on the same server.
This test would usually pass vs. an NFSv4 server that doesn't have dfdd2630a7398 ("nfsd: fix change_info in NFSv4 RENAME replies"), because
the client would end up improperly invalidating the dcache for the whole
dir after most RENAMEs.
However, this test doesn't (and shouldn't) pass on NFS, because the
client has no idea that a rename has happened on the second mount. The
expected behavior for the NFS client is for it to use the cache timeouts
in this case, which is what it now does with the above server bug fixed.
Exempt NFS from running this test, since we don't expect it to pass.
Cc: Yongcheng Yang <yoyang@redhat.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 10 Jan 2024 18:27:27 +0000 (13:27 -0500)]
generic/465: don't run it on NFS
This test kicks off a thread that issues a read against a file, while
writing to the file in 1M chunks. It expects that the reader will see
either the written data or a short read.
NFS allows DIO reads and writes to run in parallel. That means that it's
possible for them to race and the reader to see NULLs in the file if
things get reordered.
Just skip this test on NFS, since we can't guarantee that it will
reliably pass.
Chandan Babu R [Thu, 11 Jan 2024 11:58:27 +0000 (17:28 +0530)]
_scratch_xfs_mdrestore: Pass scratch log device when applicable
Metadump v2 supports dumping contents of an external log device. This commit
modifies _scratch_xfs_mdrestore() and _xfs_mdrestore() to be able to restore
metadump files which contain data from external log devices.
The callers of _scratch_xfs_mdrestore() must set the value of $SCRATCH_LOGDEV
only when all of the following conditions are met:
1. Metadump is in v2 format.
2. Metadump has contents dumped from an external log device.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chandan Babu R [Thu, 11 Jan 2024 11:58:25 +0000 (17:28 +0530)]
common/xfs: Do not append -a and -o options to metadump
xfs/253 requires the metadump to be obfuscated. However _xfs_metadump() would
append the '-o' option causing the metadump to be unobfuscated.
This commit fixes the bug by modifying _xfs_metadump() to no longer append any
metadump options. The direct/indirect callers of this function now pass the
required options explicitly.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Fri, 12 Jan 2024 05:08:33 +0000 (06:08 +0100)]
xfs/506: call _require_scratch_xfs_scrub
Call _require_scratch_xfs_scrub so that the test is _notrun on kernels
without online scrub support.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Fri, 12 Jan 2024 05:08:32 +0000 (06:08 +0100)]
xfs/262: call _require_scratch_xfs_scrub
Call _require_scratch_xfs_scrub so that the test is _notrun on kernels
without online scrub support.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Fri, 12 Jan 2024 05:08:31 +0000 (06:08 +0100)]
xfs: add a _require_scratch_xfs_scrub helper
Add a helper to call _supports_xfs_scrub with $SCRATCH_MNT and
$SCRATCH_DEV.
[zlang: rename the _scratch_require_xxx to _require_scratch_xxx]
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Fri, 12 Jan 2024 05:08:30 +0000 (06:08 +0100)]
xfs: check that the mountpoint is actually mounted in _supports_xfs_scrub
Add a sanity check that the passed in mount point is actually mounted
to guard against actually calling _supports_xfs_scrub before
$SCRATCH_MNT is mounted.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chung-Chiang Cheng [Thu, 4 Jan 2024 05:42:36 +0000 (13:42 +0800)]
README: add a missing necessary package
src/dbtest.c requires 'gdbm-ndbm.h' or 'ndbm.h', both of which are
supplied by 'libgdbm-compat-dev' in the latest Ubuntu LTS. However,
this package is not a dependency of the currently listed packages.
Therefore, add it explicitly to the necessary packages list.
Naohiro Aota [Fri, 22 Dec 2023 02:56:22 +0000 (11:56 +0900)]
fstests: btrfs: use proper filter for subvolume deletion
Test cases btrfs/208, 233, 276 does not use _filter_btrfs_subvol_delete()
to process "btrfs subvolume delete" command's output. So, the following
diff occurs even with a previous fix.
Recent btrfs-progs commit 5c91264d2dfc ("btrfs-progs: subvol delete:
print the id of the deleted subvolume") added the id of the deleted
subvolume to "Delete subvolume" print format.
As a result, btrfs/001 now always fail by the output difference.
Alexander Patrakov [Mon, 18 Dec 2023 20:57:20 +0000 (04:57 +0800)]
_require_sparse_files: rewrite as a direct test instead of a black list
_require_sparse_files was implemented as a list of filesystems known not to
support sparse files, and therefore it missed some cases.
However, if sparse files do not work as expected during a test, the risk
is that the test will write out to the disk all the zeros that would
normally be unwritten. This amounts to at least 4 TB for the generic/129
test, and therefore there is a significant media wear-out concern here.
Adding more filesystems to the list of exclusions would not scale and
would not work anyway because CIFS backed by SAMBA is safe, while CIFS
backed by Windows Server 2022 is not (because the specific write
patterns found in generic/014 and generic/129 cause it to ignore the
otherwise-supported request to make a file sparse).
Mitigate this risk by rewriting the check as a small-scale test that
reliably triggers Windows misbehavior. The black list becomes unneeded
because the same test creates and detects non-sparse files on exfat and
hfsplus.
Signed-off-by: Alexander Patrakov <patrakov@gmail.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 13 Dec 2023 22:34:45 +0000 (14:34 -0800)]
generic/735: skip this test if we cannot finsert at pos 1M
Add a _require_congruent_file_oplen to screen out filesystem
configurations that can't start a finsert operation at file pos 1M
because the fs block size isn't congruent with 1048576. For example,
xfs realtime with 28k rt extents.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 13 Dec 2023 22:34:33 +0000 (14:34 -0800)]
generic/615: fix loop termination failures
On 6.7-rc2, I've noticed that this test hangs unpredictably because the
stat loop fails to exit. While the kill $loop_pid command /should/ take
care of it, it clearly isn't.
Set up an additional safety factor by checking for the existence of a
sentinel flag before starting the loop body. In bash, "[" is a builtin
so the loop should run almost as tightly as it did before.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 4 Dec 2023 18:58:57 +0000 (20:58 +0200)]
overlay: prepare for new lowerdir+,datadir+ tests
In preparation to forking tests for new lowerdir+,datadir+ mount options,
prepare a helper to test kernel support and pass datadirs into mount
helpers in overlay/079 test.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 11 Dec 2023 06:52:24 +0000 (08:52 +0200)]
overlay: Add tests for nesting private xattrs
If overlayfs xattr escaping is supported, ensure:
* We can create "overlay.*" xattrs on a file in the overlayfs
* We can create an xwhiteout file in the overlayfs
We check for nesting support by trying to getattr an "overlay.*" xattr
in an overlayfs mount, which will return ENOTSUPP in older kernels.
Signed-off-by: Alexander Larsson <alexl@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Murphy Zhou [Fri, 15 Dec 2023 11:55:05 +0000 (19:55 +0800)]
generic: drop caches while freeze
This's a bug reproducer for a downstream kernel, upstream linux has
fixed this issue "indirectly". When the superblock is frozen and
reclaim attempts to process certain inodes that require transactions
to break down, such as those with post-eof or COW fork blocks, a
deadlock might happen.
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic: Add integrity tests with synchronous directio
This test covers data & metadata integrity check with directio with
o_sync flag and checks the file contents & size after sudden fileystem
shutdown once the directio write is completed. ext4 directio after iomap
conversion was broken in the sense that if the FS crashes after
synchronous directio write, it's file size is not properly updated.
This test adds a testcase to cover such scenario.
Man page of open says that -
O_SYNC provides synchronized I/O file integrity completion, meaning write
operations will flush data and all associated metadata to the underlying
hardware
Reported-by: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 5 Dec 2023 16:39:20 +0000 (16:39 +0000)]
generic: test reading a large directory while renaming its files
Test that on a fairly large directory if we keep renaming files while
holding the directory open and doing readdir(3) calls, we don't end up
in an infinite loop.
This exercise a bug that existed in btrfs and was fixed in kernel 6.5
by commit 9b378f6ad48c ("btrfs: fix infinite directory reads").
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
projects / users / hch / xfstests-dev.git / log