| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[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>
|
|
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>
|
|
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>
|
|
* 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Add a filter for the output of btrfs device add.
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 a filter for the output of btrfs-balance with a convert argument.
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>
|
|
[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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Create appearing to be a clone using the mkfs.btrfs option and test if
the tempfsid is active.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Use newer mkfs.btrfs option to generate two cloned devices,
used in test cases.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
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>
|
|
If another device with the same fsid and uuid would mount then verify if
it mounts with a temporary fsid.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
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>
|
|
check_fsid() provides a method to verify if the given device is mounted
with the tempfsid in the kernel. Function sb() is an internal only
function.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The -g switch to xfs_metadump turns on progress reporting, but nothing
in this test actually checks that it works.
The -o switch turns off obfuscation, which is much more critical to
support teams.
Change this test to check -o and -ao instead of -g or -ag.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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.
Reported-by: Zorro Lang <zlang@redhat.com>
Link: https://lore.kernel.org/fstests/20240205060016.7fgiyafbnrvf5chj@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com/
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Remove a whole lot of unused m4 macros from the build system.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Moving to a new test bed is always fun.
Forgot to add group fsgqa2 and tests 597, 598 failed.
generic/597 - output mismatch (see /root/xfstests-dev/results//generic/597.out.bad)
--- tests/generic/597.out 2024-01-14 08:55:20.176084268 +0000
+++ /root/xfstests-dev/results//generic/597.out.bad 2024-01-14 09:41:15.548729962 +0000
@@ -2,13 +2,17 @@
== Test symlink follow protection when
== process != link owner and dir owner != link owner
fs.protected_symlinks = 0
+chown: invalid group: 'fsgqa2:fsgqa2'
successfully followed symlink
fs.protected_symlinks = 1
+chown: invalid group: 'fsgqa2:fsgqa2'
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add the binary to gitignore, make git status clean
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The offsetof macro is causing compiler warnings since it is being
redefined, but it is anyway not used, so drop it completely.
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
On NFS, generic/089 can take a long time. There is enough contention
for the lock that it can take more than 10s (or even 60s) to acquire
it.
Bump this value up to 120s, which seems to be long enough for testing
with kdevops.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
[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>
|
|
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>
|
|
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>
|
|
The NFSv2 and v3 protocols use unsigned values for timestamps. Fix
_require_negative_timestamps() to check the NFS version and _notrun if
it's 2 or 3.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
'_require_xfs_io_command set_encpolicy -s' does not work as expected
because the following in the output of 'xfs_io -c "help set_encpolicy"':
-s LOG2_DUSIZE -- log2 of data unit size
... does not match the regex:
"^ -s ([a-zA-Z_]+ )?--"
... because the 2 in the argument name LOG2_DUSIZE is not matched. Fix
the regex to support digits in the argument name.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a new test group for testing the raid-stripe-tree feature of btrfs
with fstests.
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>
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>
|
|
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>
|
|
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.
Cc: Anna Schumaker <anna@kernel.org>
Cc: Trond Myklebust <trondmy@hammerspace.com>
Cc: Chuck Lever <chuck.lever@oracle.com>
Link: https://lore.kernel.org/linux-nfs/2f7f6d4490ac08013ef78481ff5c7840f41b1bb4.camel@kernel.org/
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Fix a comment in generic/390 to refer to the right test number.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a new test to verify if metadump/mdrestore are able to dump and restore
the contents of a dirty log.
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This commit adds the ability to test metadump v2 to existing metadump tests.
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
This commit defines a new function to help detect support for metadump v2.
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
$ dpkg -L libgdbm-compat-dev
/.
/usr
/usr/include
/usr/include/dbm.h
/usr/include/gdbm-ndbm.h
/usr/include/ndbm.h
Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The kernel patch for this test was merged into 6.7-rc4, so replace the
"xxxxxxxxxxxx" stub with the commit id.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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.
btrfs/208 - output mismatch (see /host/btrfs/208.out.bad)
--- tests/btrfs/208.out 2023-12-22 02:09:18.000000000 +0000
+++ /host/btrfs/208.out.bad 2023-12-22 02:21:40.697036486 +0000
@@ -6,12 +6,12 @@
subvol1
subvol2
subvol3
-Delete subvolume (no-commit): 'SCRATCH_MNT/subvol1'
+Delete subvolume 256 (no-commit): 'SCRATCH_MNT/subvol1'
After deleting one subvolume:
subvol2
...
Let them use the filter and fix the output accordingly.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This week, this case crashed when I test xfstests on xfs. Then, I found
this kernel patch to slove this problem, so add it.
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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.
- output mismatch (see /host/results/btrfs/001.out.bad)
--- tests/btrfs/001.out 2021-02-05 01:44:17.000000000 +0000
+++ /host/results/btrfs/001.out.bad 2023-12-15 01:43:07.000000000 +0000
@@ -33,7 +33,7 @@
Listing subvolumes
snap
subvol
-Delete subvolume 'SCRATCH_MNT/snap'
+Delete subvolume 256 (no-commit): 'SCRATCH_MNT/snap'
List root dir
subvol
...
Fix the issue by updating _filter_transaction_commit().
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
_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>
|
|
Test overlay/081 fails with:
CONFIG_OVERLAY_FS_INDEX=y
or
echo Y > /sys/modules/overlay/params/index
The reason is that mount option uuid=off has the undesired side effect
of disabling index feature.
uuid=null is exactly the same as uuid=off for the purpose of this test
but without the undesired side effect.
The test was created to test the new modes uuid=null/auto/on, so the
fact that is is testing the mode uuid=off is just an oversight.
Covert the use of uuid=off to uuid=null to fix this problem.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
Don't truncate $seqres.full every time we format a new filesystem; this
makes debugging of this weird failure:
--- /tmp/fstests/tests/generic/410.out 2023-07-11 12:18:21.642971022 -0700
+++ /var/tmp/fstests/generic/410.out.bad 2023-11-29 01:13:00.020000000 -0800
@@ -107,6 +107,9 @@ mpB/dir SCRATCH_DEV
mpC SCRATCH_DEV
mpC/dir SCRATCH_DEV
======
+mkdir: cannot create directory '/mnt/410/3871733_mpA': File exists
+mkdir: cannot create directory '/mnt/410/3871733_mpB': File exists
+mkdir: cannot create directory '/mnt/410/3871733_mpC': File exists
make-shared a slave shared mount
before make-shared run on slave shared
------
nearly impossible.
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>
|
|
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>
|
|
Fork test overlay/083 to test parsing of lowerdir+,datadir+ mount options.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Fork test overlay/079 to use the new lowerdir+,datadir+ mount options.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This patch adds -S for O_SYNC and -N for noverify option to
aio-dio-write-verify test. We will use this for integrity
verification test for aio-dio.
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>
|
|
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>
|
|
Append writes to a file with logical block numbers close to 0xffffffff and
observe if a kernel crash is caused by ext4_lblk_t overflow triggering
BUG_ON at ext4_mb_new_inode_pa(). This is a regression test for commit
bc056e7163ac ("ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow")
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/301 makes detailed size calculations to test squota edge cases
which rely on assumptions that break down with compression enabled.
Fix it by disabling the test with compression. Compression + squotas
still gets quite solid test coverage via squotas support in fsck and
normal compression enabled fstests runs.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Hardcoded subvolids break test runs with no free-space-tree, so change
the test to use _btrfs_get_subvolid instead of assuming 256, 257, etc...
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test checks the expectaion from old kernels that set/get of
trusted.overlay.* xattrs is not supported on an overlayfs filesystem.
New kernels support set/get xattr of trusted.overlay.* xattrs, so adapt
the test to check that either both set and get work on new kernel, or
neither work on old kernel.
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>
|
|
This test case exercises subvolumes, snapshot and send/receive, so add
the corresponding groups to the test.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There are several btrfs test that exercise compression in one way or
another but are not listed as part of the 'compress' group, so add them
to that group.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This new test called quota rescan directly rather than with the new
wrapper. As a result, it failed with -O squota in MKFS_OPTIONS. Using
the wrapper, it skips the rescan and passes again.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
generic/459 occasionally fails on bcachefs because the deliberately
induced I/O errors caused by exhausting the overprovisioned thin
pool can lead to filesystem shutdown. This test considers this
expected behavior on certain fs', but only checks for the ext4
remount read-only behavior. bcachefs does a similar emergency
read-only transition in response to certain I/O errors, but it
behaves more similar to an XFS shutdown and doesn't necessarily
reflect "ro" state in the mount table (unless induced by userspace).
Since the test already runs a touch command to help trigger the ext4
error handling sequence, this can be tweaked to serve double duty
and also more accurately detect read-only status on bcachefs.
Refactor into a small helper, check for touch command failure, and
consider the fs read-only if either that or the mount entry check
indicates it.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Wrap offset, length within '[]' and remove meanless 't' in
do_fallocate().
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This is a deprecated option and it's going away with the new mount api
patches, so remove this from the test.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Several test cases under tests/btrfs are missing from the remount
group. This patch adds the test cases that use -o remount to the remount
group.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test requires both the xfs_io falloc and fpunch commands to run.
falloc isn't supported on alwayscow=1 mounts, which means this test
fails there.
While we're at it, update the commit id since the fix was committed to
6.7-rc2.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
As per last week's discussion, xfs/601 doesn't have any xfs-specific
functionality in it. Turn it into a generic test.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This is a regression test for patch "xfs: fix internal error from AGFL
exhaustion"), which is not yet merged. Without the fix, it will fail
with a "Structure needs cleaning" error.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Since the new 'exchange range' functionality is no longer a VFS level
concept, the xfs_io swapext -v options have changed. Update fstests to
reflect this new reality.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I'm abandoning (for now) efforts to bring atomic file content exchanges
to the VFS. The goal here is to reduce friction in getting online fsck
merged, so Dave and I want to take this back to being a private XFS
ioctl so we can explore with it for a while before committing it to the
stable KABI.
Shift all the existing FIEXCHANGE usage to XFS_IOC_EXCHANGE_RANGE, and
try to pick it up from xfs_fs_staging.h if the system xfslibs-dev
package has such an animal.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
On machine with using raid, this case will trigger
the following error:
==== NO CRC ====
+mkfs.xfs: small data volume, ignoring data volume stripe unit 512 and stripe width 512
== Options: rw ==
== Options: usrquota,rw ==
mkfs.xfs generates this error since xfsprogs commit 42371fb36
("mkfs: ignore data blockdev stripe geometry for small filesystems").
It disables automatic detection of stripe unit and width if the
data device is less than 1GB.
But, since xfstests commit baaa392c("xfs/263: don't hardcode inode numbers in output"),
we don't care the inode number. So let's remove this data section size argument
instead of increasing this size to 1G, then we can solve this false
positive.
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
[BUG]
There is a sysbot regression report about transaction abort during
snapshot creation, which is caused by the new timing of qgroup creation
and too strict error check.
[FIX]
The proper fix is already submitted, with the title "btrfs: do not abort
transaction if there is already an existing qgroup".
[TEST]
The new test case would reproduce the regression by:
- Create a subvolume and a snapshot of it
- Record the subvolumeid of the snapshot
- Re-create the fs
Since btrfs won't reuse the subvolume id, we have to re-create the fs.
- Enable quota and create a qgroup with the same subvolumeid
- Create a subvolume and a snapshot of it
For unpatched and affected kernel (thankfully no release is affected),
the snapshot creation would fail due to aborted transaction.
- Make sure the subvolume id doesn't change for the snapshot
There is one very hacky attempt to fix it by avoiding using the
subvolume id, which is completely wrong and would be caught by this
extra check.
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: Zorro Lang <zlang@kernel.org>
|
|
Create a test to exercise recovery of unlinked inodes on a clean
filesystem. This was definitely possible on old kernels that on an ro
mount would clean the log without processing the iunlink list.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
A handful of tests write things to /dev/ttyprintk to make it easier to
pinpoint where in a test something went wrong. This isn't entirely
robust, however, because ttyprintk is an optional feature. In the grand
tradition of kernel design there's also a /dev/kmsg that does nearly the
same thing, is also optional, and there's no documentation spelling out
when one is supposed to use one or the other.
So.
Create a pair of helpers to append messages to the kernel log. One
simply writes its arguments to the kernel log, and the other writes
stdin to the kernel log, stdout, and any other files specified as
arguments.
Underneath the covers, both functions will send the message to
/dev/ttyprintk if available. If it isn't but /dev/kmsg is, they'll
send the messages there, prepending a "[U]" to emulate the only
discernable difference between ttyprintk and kmsg.
If neither are available, then either /dev or the kernel aren't allowing
us to write to the kernel log, and the messages are not logged. The
second helper will still write the messages to stdout.
If this seems like overengineered nonsense, then yes it is.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
XFS has a rather slow reflink operation. While a reflink operation is
running, other programs cannot read the contents of the source file,
which is causing latency spikes. Catherine Hoang wrote a patch to
permit reads, since the source file contents do not change. This is a
functionality test for that patch.
[zlang@ adds `_supported_fs generic`]
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Catherine Hoang <catherine.hoang@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
We have two instances of reading the btrfs fsid by using the command
'btrfs filesystem show <mnt>' turn this into an easy-to-use helper
function and also use it.
Suggested-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add this test case back to the auto group which reverts the
commit e2e7b549380a ("fstests: btrfs/219: remove it from auto group") since
the previously missing kernel commit 5f58d783fd78 ("btrfs: free device in
btrfs_close_devices for a single device filesystem") has already been
integrated.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test case checks for failure of the cloned device mounts, which
is no longer true after the commit a5b8a5f9f835 ("btrfs: support
cloned-device mount capability"). So check for the non-presence the
temp-fsid feature and do not test for the failure of the cloned device
mount.
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202310251645.5fe5495a-oliver.sang@intel.com
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When we fail with the message 'We were allowed to mount when we should
have failed,' it will fail to clean up the loop devices, making it
difficult to run further test cases or the same test case again.
So we need a 2nd loop device local variable to release it. Let's
reorganize the local variables to clean them up in the _cleanup() function.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
With this helper, btrfs test cases can now check if a particular feature
is implemented in the kernel.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Currently _fs_sysfs_dname gets fsid from the findmnt command however
this command provides the metadata_uuid if the device is mounted with
temp-fsid. So instead, use btrfs filesystem show command to know the fsid.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
xfs/146 uses the xfs_io falloc subcommand and thus kernel fallocate
support. Ensure the support is present.
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>
|
|
xfs_io pwrite issues a series of block size writes, but there is no
guarantee that the resulting extent(s) will be singular or contiguous.
This behavior is acceptable, but the test is flawed in that it expects
a single extent for a pwrite.
Modify test to use actual blocksize for pwrite and reflink. Also
modify it to accommodate pwrite and reflink that produce different
mapping results.
Signed-off-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test that snapshotting a new subvolume (created in the current transaction)
that has a btree with a height > 1, works and does not result in a fs
corruption.
This exercises a regression introduced in kernel 6.5 by the kernel commit:
1b53e51a4a8f ("btrfs: don't commit transaction for every subvol create")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Check parsing and display of spaces and escaped colons and commans in
lowerdir mount option.
This is a regression test for two bugs introduced in v6.5 with the
conversion to new mount api.
There is another regression of new mount api related to libmount parsing
of escaped commas, but this needs a fix in libmount - this test only
verifies the fixes in the kernel, so it uses LIBMOUNT_FORCE_MOUNT2=always
to force mount(2) and kernel pasring of the comma separated options list.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Every now and then, this test fails with the following output when
running against my development tree when configured with an 8k fs block
size:
--- a/tests/generic/251.out 2023-07-11 12:18:21.624971186 -0700
+++ b/tests/generic/251.out.bad 2023-10-15 20:54:44.636000000 -0700
@@ -1,2 +1,4677 @@
QA output created by 251
Running the test: done.
+fstrim: /opt: FITRIM ioctl failed: Invalid argument
+fstrim: /opt: FITRIM ioctl failed: Invalid argument
...
+fstrim: /opt: FITRIM ioctl failed: Invalid argument
Dumping the exact fstrim command lines to seqres.full produces this at
the end:
/usr/sbin/fstrim -m 32544k -o 30247k -l 4k /opt
/usr/sbin/fstrim -m 32544k -o 30251k -l 4k /opt
...
/usr/sbin/fstrim -m 32544k -o 30255k -l 4k /opt
The count of failure messages is the same as the count as the "-l 4k"
fstrim invocations. Since this is an 8k-block filesystem, the -l
parameter is clearly incorrect. The test computes random -m and -l
options.
Therefore, create helper functions to guess at the minimum and maximum
length and minlen parameters that can be used with the fstrim program.
In the inner loop of the test, make sure that our choices for -m and -l
fall within those constraints.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Zorro complained that the next patch caused him a regression:
generic/251 249s ... [failed, exit status 1]- output mismatch (see /root/git/xfstests/results//generic/251.out.bad)
--- tests/generic/251.out 2022-04-29 23:07:23.263498297 +0800
+++ /root/git/xfstests/results//generic/251.out.bad 2023-10-22 14:17:07.248059405 +0800
@@ -1,2 +1,5 @@
QA output created by 251
Running the test: done.
+5838a5839
+> aa60581221897d3d7dd60458e1cca2fa ./results/generic/251.full
+!!!Checksums has changed - Filesystem possibly corrupted!!!\n
...
(Run 'diff -u /root/git/xfstests/tests/generic/251.out /root/git/xfstests/results//generic/251.out.bad' to see the entire diff)
Ran: generic/251
Failures: generic/251
Failed 1 of 1 tests
The next patch writes some debugging information into $seqres.full,
which is a file underneat $RESULT_BASE. If the test operator does not
set RESULT_BASE, it will be set to a subdir of $here by default. Since
this test also snapshots the contents of $here before starting its loop,
any logging to $seqres.full on such a system will cause the post-copy
checksum to fail due to a mismatch.
Fix all this by copying $here to $SCRATCH_DEV and checksumming the copy
before the FITRIM stress test begins to avoid problems with $seqres.full.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
A btrfs device add command issues a trim on the device if the device
supports trim, and then it outputs a message to stdout informing that it
performed a trim. If that happens it breaks the golden output and the
test fails like this:
$ ./check btrfs/298
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.6.0-rc3-btrfs-next-139+ #1 SMP PREEMPT_DYNAMIC Tue Oct 3 13:52:02 WEST 2023
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/298 - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/298.out.bad)
--- tests/btrfs/298.out 2023-10-18 23:29:06.029292800 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/298.out.bad 2023-10-19 10:54:29.693210881 +0100
@@ -1,2 +1,3 @@
QA output created by 298
+Performing full device TRIM /dev/sdd (100.00GiB) ...
Silence is golden
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/298.out /home/fdmanana/git/hub/xfstests/results//btrfs/298.out.bad' to see the entire diff)
Ran: btrfs/298
Failures: btrfs/298
Failed 1 of 1 tests
Fix this by redirecting the device add's stdout to the $seqres.full file.
Any device add errors are sent to stderr, so we'll notice if errors happen
due to possible future regressions, as it will break the golden output.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Coreutils commit 3cb862ce5f10 ( mv: better diagnostic for 'mv dir x' failure)
was released in v9.4, changed the error message from
'mv: cannot move 'b/t' to 'a/t': Directory not empty' to
'mv: cannot overwrite 'a/t': Directory not empty' in case of
EDQUOT/EEXIST/EISDIR/EMLINK/ENOSPC/ENOTEMPTY/ETXTBSY.
The change breaks generic/245 due to the mismatched output:
generic/245 1s ... - output mismatch (see /root/xfstests-dev/results//generic/245.out.bad)
--- tests/generic/245.out 2023-10-05 11:15:21.124295738 +0800
+++ /root/xfstests-dev/results//generic/245.out.bad 2023-10-05 11:15:23.456315468 +0800
@@ -1,2 +1,2 @@
QA output created by 245
-mv: cannot move 'TEST_DIR/test-mv/ab/aa/' to 'TEST_DIR/test-mv/aa': File exists
+mv: cannot overwrite 'TEST_DIR/test-mv/aa': File exists
...
(Run 'diff -u /root/xfstests-dev/tests/generic/245.out /root/xfstests-dev/results//generic/245.out.bad' to see the entire diff)
Filter out and replace mv error messages to fix the test.
Signed-off-by: Su Yue <glass.su@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add _require_scratch to a bunch of test that were using $SCRATCH_DEV
without that check.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
_require_dm_target tries to use $SCRATCH_DEV, so move it after we've
established that the configuration has a valid $SCRATCH_DEV.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a regression test for funsharing uncached files to ensure that we
actually manage the pagecache state correctly.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Prior to commit f55e46d629, these two tests would run fsstress until it
hit a failure -- ENOSPC in the case of generic/269, and EIO in the case
of xfs/051. These errors are expected, which was why stderr was also
redirected to /dev/null. Commit f55e46d629 removed the stderr
redirection, which has resulted in a 100% failure rate.
Fix this regression by pushing stderr stream to $seqres.full.
Fixes: f55e46d629 ("fstests: redirect fsstress' stdout to $seqres.full instead of /dev/null")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test does a strange thing with directio -- it races a reader thread
with an appending aio writer thread and checks that the reader thread
only ever sees a (probably short) buffer containing the same contents
that are being read.
However, this has never worked correctly on XFS, which supports
concurrent readers and writers for directio. Say you already have a
file with a single written mapping A:
AAAAAAAAAA
0 EOF
Then one thread initiates an aligned appending write:
AAAAAAAAAA---------
0 EOF new_EOF
However, the free space is fragmented, so the file range maps to
multiple extents b and c (lowercase means unwritten here):
AAAAAAAAAAbbbbccccc
0 EOF new_EOF
This implies separate bios for b and c. Both bios are issued, but c
completes first. The ioend for c will extend i_size all the way to
new_EOF. Extent b is still marked unwritten because it hasn't completed
yet.
Next, the test reader slips in and tries to read the range between the
old EOF and the new EOF. The file looks like this now:
AAAAAAAAAAbbbbCCCCC
0 EOF new_EOF
So the reader sees "bbbbCCCCC" in the mapping, and the buffer returned
contains a range of zeroes followed by whatever was written to C.
For pagecache IO I would say that i_size should not be extended until
the extending write is fully complete, but the pagecache also
coordinates access so that reads and writes cannot conflict.
However, this is directio. Reads and writes to the storage device can
be issued and acknowledged in any order. I asked Ted and Jan about this
point, and they echoed that for directio it's expected that application
software must coordinate access themselves.
In other words, the only thing that the reader can check here is that
the filesystem is not returning stale disk contents. Amend the test so
that null bytes in the reader buffer are acceptable.
Cc: tytso@mit.edu
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When I added an fstests config for "RAID" striping (aka MKFS_OPTIONS='-d
su=128k,sw=4'), I suddenly started seeing this test fail sporadically
with:
--- /tmp/fstests/tests/xfs/178.out 2023-07-11 12:18:21.714970364 -0700
+++ /var/tmp/fstests/xfs/178.out.bad 2023-07-25 22:05:39.756000000 -0700
@@ -10,6 +10,20 @@ bad primary superblock - bad magic numbe
attempting to find secondary superblock...
found candidate secondary superblock...
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
verified secondary superblock...
writing modified primary superblock
sb root inode INO inconsistent with calculated value INO
Eventually I tracked this down to a mis-interaction between the test,
xfs_repair, and the storage device.
If the device doesn't support discard, _scratch_mkfs won't zero the
entire disk to remove old dead superblocks that might have been written
by previous tests. After we shatter the primary super, the xfs_repair
scanning code can still trip over those old supers when it goes looking
for secondary supers.
Most of the time it finds the actual AG 1 secondary super, but sometimes
it finds ghosts from previous formats. When that happens, xfs_repair
will talk quite a bit about those failed secondaries, even if it
eventually finds an acceptable secondary sb and completes the repair.
Filter out the messages about secondary supers.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Overlayfs-tools and overlayfs-progs projects have been merged together.
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Update the commit id in the _fixed_by tag now that we've merged the
kernel fixes.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
If we place /var/lib/xfstests on a read-only filesystem, commands in
_link_out_file_named() fail to modify the files. However, they won't fail
the test. As a result, the test case fails mysteriously with only "no
qualified output" printed.
Fix it by checking the error case.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Compilers complain about the function prototype otherwise
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>
Cc: Zorro Lang <zlang@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Make sure the installed unshare binary supports all the arguments that
it wants to use. The unshare program on my system (Ubuntu 22.04)
doesn't support --map-auto, so this test fails unnecessarily.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Skip this test if larp mode doesn't work.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The regular expression used by _scratch_mkfs_geom() to match mkfs.xfs' block
size argument interprets the character 'b' as optional. It should actually
interpret whitespace as optional.
This causes generic/223 to fail when testing an XFS filesystem which uses an
external log device along with the -lsize option. In this case, the original
value of -lsize is replaced with the value of $blocksize.
_scratch_mkfs_sized() also uses the same incorrect regex.
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a new test to ckeck file move (rename) operation among
different mount points which are mounting to a same export.
This should be a simple test but it recently unveils an ancient
nfsd bug. Thus let's make it to be a regresstion check.
Signed-off-by: Yongcheng Yang <yoyang@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
We use _pwrite_byte to corrupt the root node, but such overwrite won't work
on a sequential write required zone. So, skip the test on a zoned device.
Technically, we can run this test case by checking if the physical location
lands in a conventional zone. But, the logic should be no difference than
the regular mode and I don't think it's worth doing so.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Recently, in the kernel commit 0d9436739af2 ("btrfs: scan but don't
register device on single device filesystem"), we adopted an approach
where we scan the device to validate it. However, we do not register
it in the kernel memory since it is not required to be remembered.
However, the seed device should continue to be registered because
otherwise, the mount operation for the sprout device will fail.
This patch ensures that we honor the mount requirements and do not break
anything while making changes in this part of the code.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
After doing log replay, btrfs/192 is overwriting the $seqres.full file
because it uses the plain ">" redirect operator, instead of an append
">>" redirect operator. As a consequence it is overriding the file and
eliminating any previous output that may be useful to debug a test
failure (such as the fsstress seed or mkfs results). So use >> instead
of >.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Several tests are redirecting the output of fsstress to /dev/null and this
makes it harder to debug a test failure because we have no way of knowing
what was the seed used by fsstress, as fsstress outputs the seed it uses
to stdout. Very often when such a test fails, I have to go modify to
redirect stdout to the $seqres.full file and then run it in a loop until
I find a seed that causes a failure.
So modify all tests that redirect fsstress' output to /dev/null to instead
redirect it to the $seqres.full file. Note that for some tests I've added
the style ">> $seqres.full" (with a space after >>) while for others I did
">>$seqres.full" (no space) - the reason for this was to keep style
consistency within each test case.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The file size written below is 10 MB, but the variable is set to 1 MB. Fix
it, or the test will fail.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
On the zoned mode, the extent size is limited also by
queue/zone_append_max_bytes. This breaks the assumption that the file "foo"
has a single extent and corrupts the test output.
It is difficult to support the case, so let's just skip the test in this
case.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
These tests cannot succeed if mkfs enable squotas, as they either test
the specifics of qgroups behavior or they test *enabling* squotas. Skip
these in squota mode.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
These tests can pass in simple quota mode if we skip the rescans via the
wrapper.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Many btrfs tests explicitly trigger quota rescan. This is not a
meaningful operation for simple quotas, so we wrap it in a helper that
doesn't blow up quite so badly and lets us run those tests where the
rescan is a qgroup detail.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test some interesting basic and edge cases of simple quotas.
To some extent, this is redundant with the alternate testing strategy of
using MKFS_OPTIONS to enable simple quotas, running the full suite and
relying on kernel warnings and fsck to surface issues.
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
To facilitate skipping tests depending on the qgroup mode after mkfs,
add support for figuring out the mode. This cannot just rely on the new
sysfs file, since it might not be present on older kernels.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Expand the has/get/require functions to allow passing a dev by
parameter, and implement the test_dev specific one in terms of the new
generic one.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When running btrfs/287 with features that create extra trees or don't
the need to create some trees, such as when using the free space tree
(default for several btrfs-progs releases now) versus when not using
it (by passing -R ^free-space-tree in MKFS_OPTIONS), the test can fail
because the IDs for the two snapshots it creates changes, and the golden
output is requiring the numeric IDs of the snapshots.
For example, when disabling the free space tree, the test fails like this:
$ MKFS_OPTIONS="-R ^free-space-tree" ./check btrfs/287
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.6.0-rc2-btrfs-next-138+ #1 SMP PREEMPT_DYNAMIC Thu Sep 21 17:58:48 WEST 2023
MKFS_OPTIONS -- -R ^free-space-tree /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/287 1s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/287.out.bad)
--- tests/btrfs/287.out 2023-09-22 12:39:43.060761389 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/287.out.bad 2023-09-22 12:40:54.238849251 +0100
@@ -44,52 +44,52 @@
Create a readonly snapshot of 'SCRATCH_MNT' in 'SCRATCH_MNT/snap1'
Create a readonly snapshot of 'SCRATCH_MNT' in 'SCRATCH_MNT/snap2'
resolve first extent:
-inode 257 offset 16777216 root 257
-inode 257 offset 8388608 root 257
-inode 257 offset 16777216 root 256
-inode 257 offset 8388608 root 256
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/287.out /home/fdmanana/git/hub/xfstests/results//btrfs/287.out.bad' to see the entire diff)
HINT: You _MAY_ be missing kernel fix:
0cad8f14d70c btrfs: fix backref walking not returning all inode refs
Ran: btrfs/287
Failures: btrfs/287
Failed 1 of 1 tests
So add a filter to logical reserve calls to replace snapshot root IDs with
a logical name (snap1 and snap2).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Avoid using the shortcut "sub" for the "subvolume" command, as this is the
standard practice because such shortcuts are not guaranteed to exist in
every btrfs-progs release (they may come and go). Also make the variables
local.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
It prints "File extent layout before defrag" for the both outputs, but the
latter one should be "after defrag".
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test that if names are added to a directory after an opendir(3) call and
before a rewinddir(3) call, future readdir(3) calls will return the names.
This is mandated by POSIX:
https://pubs.opengroup.org/onlinepubs/007904875/functions/rewinddir.html
This exercises a regression in btrfs which is fixed by a kernel patch that
has the following subject:
""btrfs: refresh dir last index during a rewinddir(3) call""
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Running btrfs/239 on a zoned device often fails with the following error.
btrfs/239 5s ... - output mismatch (see /host/btrfs/239.out.bad)
--- tests/btrfs/239.out 2023-09-21 16:56:37.735204924 +0900
+++ /host/btrfs/239.out.bad 2023-09-21 18:22:45.401433408 +0900
@@ -1,4 +1,6 @@
QA output created by 239
+/testdir/dira still exists
+/dira does not exists
File SCRATCH_MNT/testdir/file1 data:
0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
*
...
This happens because "testdir" and "dira" are not logged on the first fsync
(fsync $SCRATCH_MNT/testdir), but are written as a full commit. That
prevents updating the log on "mv" time, leaving them pre-mv state.
The full commit is induced by the creation of a new block group. On the
zoned mode, we use a dedicated block group for tree-log. That block group
is created on-demand or assigned to a metadata block group if there is
none. On the first mount of a file system, we need to create one because
there is only one metadata block group available for the regular
metadata. That creation of a new block group forces tree-log to be a full
commit on that transaction, which prevents logging "testdir" and "dira".
Fix the issue by calling fsync before the first "sync", which creates the
dedicated block group and let the files be properly logged.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
A few tests were still using the older style of mentioning the fix in the
comment section. This patch migrates them to using
_fixed_by_kernel_commit.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test for a regression in copy up of symlink that has the S_NOATIME
inode flag.
This is a regression from v5.15 reported by Ruiwen Zhao:
https://lore.kernel.org/linux-unionfs/CAKd=y5Hpg7J2gxrFT02F94o=FM9QvGp=kcH1Grctx8HzFYvpiA@mail.gmail.com/
In the bug report, the symlink has the S_NOATIME inode flag because it is
on an NFS/FUSE filesystem that sets S_NOATIME for all inodes.
The reproducer uses another technique to create a symlink with
S_NOATIME inode flag by using chattr +A inheritance on filesystems
that inherit chattr flags to symlinks.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The tests btrfs/288, btrfs/289 and btrfs/300 are using the "xxxx..." stub
for commit ids, as when they were submitted/merged the corresponding
btrfs patches were not yet in Linus' tree. So replace the stubs with the
commit ids.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The fix commit is written in the comment without a commit hash. Use
_fixed_by_kernel_commit command to describe it.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Running btrfs/076 on a zoned null_blk device will fail with the following error.
- output mismatch (see /host/results/btrfs/076.out.bad)
--- tests/btrfs/076.out 2021-02-05 01:44:20.000000000 +0000
+++ /host/results/btrfs/076.out.bad 2023-09-15 01:49:36.000000000 +0000
@@ -1,3 +1,3 @@
QA output created by 076
-80
-80
+83
+83
...
This is because the default value of zone_append_max_bytes is 127.5 KB
which is smaller than BTRFS_MAX_UNCOMPRESSED (128K). So, the extent size is
limited to 126976 (= ROUND_DOWN(127.5K, 4096)), which makes the number of
extents larger, and fails the test.
Instead of hard-coding the number of extents, we can calculate it using the
max extent size of an extent. It is limited by either
BTRFS_MAX_UNCOMPRESSED or zone_append_max_bytes.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I wanted to verify tests using the command "btrfs scrub start" and
found that there are many more test cases using "btrfs scrub start"
than what is listed in the group.list file. So, get them to the scrub
group.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Currently, _get_max_file_size finds max file size on $TEST_DIR.
The tests/generic/692 uses this function to detect file size and
then tries to create a file on $SCRATCH_MNT.
This works fine when test and scratch filesystems have the same
block size. However, it will fail if they differ.
Make _get_max_file_size accept mount point on which to detect max
file size.
Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Some test cases lack executable permission ('x'). Before running each
test case, `./check` checks and grants them 'x' permission. However,
this always leads to a dirty git repo. And the absence of 'x' permission
in test cases is often overlooked during reviews.
Since maintainers use mvtest to assign new case, add this change for
convenience of maintainers.
Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
As we are obliterating the need for the device scan for the single device,
which will return success if the basic superblock verification passes,
even for the duplicate device of the mounted filesystem, drop the check
for the return code in this testcase and continue to verify if the device
path of the mounted filesystem remains unaltered after the scan.
Also, if the test fails, it leaves the local non-standard mount point
remained mounted, leading to further test cases failing. Call unmount
in _cleanup().
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test overlayfs fsid behavior with new mount options uuid=null/on
that were introduced in kernel v6.6:
- Test inherited upper fs fsid with mount option uuid=off/null
- Test uuid=null behavior for existing overlayfs by default
- Test persistent unique fsid with mount option uuid=on
- Test uuid=on behavior for new overlayfs by default
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Make sure that log recovery will not succeed if there are unknown
rocompat features in the superblock and the log is dirty.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Make sure we can actually read files off the ro mounted filesystem that
has an unknown rocompat feature set.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
We don't need scrub status; it is okay to ignore the warnings due to
the readonly /var/lib/btrfs if any. Redirect stderr to seqres.full.
We check the scrub return status.
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.42fad803-d505-48f4-a04d-612dbf8bd724: Read-only file system. Progress cannot be queried
+WARNING: failed to write the progress status file: Read-only file system. Status recording disabled
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There are two repair functions: _repair_scratch_fs() and
_repair_test_fs(). As the names suggest, these functions are designed to
repair the filesystems SCRATCH_DEV and TEST_DEV, respectively. However,
these functions never called proper comamnd for the filesystem type btrfs.
This patch fixes it. Thx.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The write invalidation code in iomap can only be triggered for writes
that span multiple folios. If the kernel reports a huge page size,
scale up the write size.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This function does not follow the naming convention that common helpers
must start with an underscore. Fix this.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This helper has two parts -- querying the value, and _notrun'ing the
test if huge pages aren't turned on. Break these into the usual
_require_hugepages and _get_hugepagesize predicates so that we can adapt
xfs/559 to large folios being used for writes.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I run fstests in a readonly container, and accidentally uninstalled the
btrfsprogs package. When I did, this test started faililng:
--- btrfs/282.out
+++ btrfs/282.out.bad
@@ -1,3 +1,7 @@
QA output created by 282
wrote 2147483648/2147483648 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+WARNING: cannot create scrub data file, mkdir /var/lib/btrfs failed: Read-only file system. Status recording disabled
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.3e1cf8c6-8f8f-4b51-982c-d6783b8b8825: No such file or directory. Progress cannot be queried
+WARNING: cannot create scrub data file, mkdir /var/lib/btrfs failed: Read-only file system. Status recording disabled
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.3e1cf8c6-8f8f-4b51-982c-d6783b8b8825: No such file or directory. Progress cannot be queried
Skip the test if /var/lib/btrfs isn't writable, or if /var/lib isn't
writable, which means we cannot create /var/lib/btrfs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test is unreliable on NFS. It fails consistently when run vs. a
server exporting btrfs, but passes when the server exports xfs. Since we
don't have any sort of attribute that we can require to test this, just
skip this one on NFS.
Also, subsume the check for btrfs into the _supported_fs check, and add
a comment for it.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
NFS doesn't keep track of whether a file is reflinked or not, so it
doesn't prevent this behavior. It shouldn't be a problem for NFS anyway,
so just skip this test there.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When creating a new dentry (of any type), NFS will optimize away any
on-the-wire lookups prior to the create since that means an extra
round trip to the server. Because of that, it consistently fails this
test.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There are several generic tests that require "setcap", but don't check
whether the underlying fs supports security attrs. Add the appropriate
checks.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test requires FIEMAP support.
Suggested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
_require_acl tests whether you're able to fetch the ACL from a file
using chacl, and then tests for an -EOPNOTSUPP error return.
Unfortunately, filesystems that don't support them (like NFSv4) just
return -ENODATA when someone calls getxattr for the POSIX ACL, so the
test doesn't work.
Fix the test to have chacl set an ACL on the file instead, which should
reliably fail on filesystems that don't support them.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Now that I've finally gotten liburing installed on my test machine, I
can actually test io_uring. Adapt these two tests to support
SOAK_DURATION so I can add it to that too.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Ritesh Harjani reported that mount and unmount can race with the xfs cpu
hotplug notifier hooks and crash the kernel, which isfixed by:
https://lore.kernel.org/linux-xfs/ZO6J4W9msOixUk05@dread.disaster.area/T/#t
Extend this test to include that.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Make this test controllable via SOAK_DURATION, for anyone who wants to
perform a long soak test of filesystem vs. cpu hotplug.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Since commit 3687fcb0752a ("btrfs: zoned: make auto-reclaim less
aggressive"), the reclaim process won't run unless the 75% (by default) of
the filesystem volume is allocated as block groups. As a result, btrfs/237
won't success when it is run with a large volume.
To run the reclaim process, we need to either fill the FS to the desired
level, or make a small FS so that the test write can go over the level.
Since the current test code expects the FS has only one data block group,
filling the FS is both cumbersome and need effort to rewrite the test code.
So, we take the latter method. We create a small (16 * zone size) FS. The
size is chosen to hold a minimal FS with DUP metadata setup.
However, creating a small FS is not enough. With SINGLE metadata setup, we
allocate 3 zones (one for each DATA, METADATA and SYSTEM), which is less
than 75% of 16 zones. We can tweak the threshold to 51% on regular btrfs
kernel config (!CONFIG_BTRFS_DEBUG), but that is still not enough to start
the reclaim process. So, this test requires CONFIG_BTRFS_DEBUG to set the
threshold to 1%.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
xfs_io pwrite issues a series of block size writes, but there is no
guarantee that the resulting extent(s) will be singular or contiguous.
This behavior is acceptable, but the test is flawed in that it expects
a single extent for a pwrite.
Modify test to limit pwrite and reflink to a single block.
Signed-off-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Dave Chinner reported that xfs/273 fails if the AG size happens to be an
exact power of two. I traced this to an agbno integer overflow when the
current GETFSMAP call is a continuation of a previous GETFSMAP call, and
the last record returned was non-shareable space at the end of an AG.
This is the regression test for that bug.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When the AIO program failed, it is better to bail out the test to keep the
failed state intact.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When short read or corruption happened, it is difficult to locate which IO
event failed. Print the address to make it identifiable.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The async write IOs can return some errors, which may lead to a short read or
corruption in io_verify() stage. Catch an error early to identify the root
cause easily.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I remember this case fails on last year becuase of
kernel commit cae2de69 ("iomap: Add async buffered write support")
kernel commit 1aa91d9 ("xfs: Add async buffered write support").
as below:
pwrite: Resource temporarily unavailable
wrote 8388608/8388608 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-RWF_NOWAIT time is within limits.
+pwrite: Resource temporarily unavailable
+(standard_in) 1: syntax error
+RWF_NOWAIT took seconds
So For async buffered write requests, the request will return -EAGAIN
if the ilock cannot be obtained immediately.
Here also a discussion[1] that seems generic/471 has been broken.
Now, I met this problem in my linux distribution, then I found the above
discussion. IMO, remove this case is ok and then we can avoid to meet this
false report again.
[Additional information from Dave Chinner]
We changed how timestamps are updated so that they are aware of
IOCB_NOWAIT. If the IOCB_NOWIAT DIO write now needs to update the
inode timestamps, it will return -EAGAIN instead of doing
potentially blocking operations that require IO to complete (i.e.
taking a transaction reservation).
Hence the first time we go to do a DIO read an inode, it's going to
do an atime update, which now occurrs from an IOCB_NOWAIT context
and we return -EAGAIN....
Yes, we added non-blocking timestamp updates as part of the async
buffered write support, but this was a general XFS IO path change of
behaviour to address a potential blocking point in *all* IOCB_NOWAIT
reads and writes, buffered or direct.
The test is not validating that RWF_NOWAIT is behaving correctly - it
just was a simple operation that kinda exercised RWF_NOWAIT semantics
when we had no other way to test this code. It has outlived it's
original purpose, so it should be removed...
[1]https://lore.kernel.org/linux-xfs/b2865bd6-2346-8f4d-168b-17f06bbedbed@kernel.dk/
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
