| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
As of xfsprogs commit 6e0ed3d1 ("mkfs: stop allowing tiny filesystems")
attempts to create XFS filesystems sized under 300M fail, unless
TEST_DIR, TEST_DEV and QA_CHECK_FS environment variables are exported
(or a --unsupported mkfs parameter is provided).
TEST_DIR and QA_CHECK_FS are already exported, while TEST_DEV may only
be locally set if provided via e.g. configs/$HOSTNAME.config. Explicitly
export TEST_DEV to ensure that tests which call _scratch_mkfs_sized()
with an fssize under 300M run normally.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When build xfstests in some platform it will return
no-return-in-nonvoid-function error in dio-buf-fault.c:83 and
fake-dump-rootino.c:224, add return value to solve the issue.
Signed-off-by: Yong Sun <yosun@suse.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Given that ext4 also allows mounting of a cloned filesystem, the btrfs
test case btrfs/312, which assesses the functionality of cloned
filesystem support, can be refactored to be under the generic group.
So add _require_duplicated_fsid helper, then move btrfs/312 to generic.
[zlang: remove "quick" group, change the cleanup of g/744 a bit]
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 btrfs-corrupt-block -v has been replaced with --value so fix it.
_fsv_scratch_corrupt_merkle_tree() uses the btrfs-corrupt-block
--value option, so add the "value" prerequisite in the function
_require_fsverity_corruption.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Checks if the running btrfs-corrupt-block also has the options value and
offset.
Remove btrfs-corrupt-block command's STDOUT and STDERR output redirection
to /dev/null. Without this, debugging wasn't possible. I also noticed that
command is quiet when successfull, so no redirect to $seqres.full is required.
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 -v and -o short options in btrfs-corrupt-block were introduced and
replaced with the long options --value and --offset in the same
btrfs-progs release 5.19 by the following commits:
b2ada0594116 ("btrfs-progs: corrupt-block: corrupt generic item data")
22ffee3c6cf2 ("btrfs-progs: corrupt-block: use only long options for value and offset")
We hope that if these commits are backported, they are both backported at
the same time.
Use only the long options of btrfs-corrupt-block in the test cases. Also,
check if btrfs-corrupt-block has the options --value and --offset.
[zlang: use -w option for grep, and remove "ret" local value]
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
[BUG]
All the touched test cases would fail after btrfs-progs commit
5f87b467a9e7 ("btrfs-progs: subvolume: output the prompt line only when
the ioctl succeeded") due to golden output mismatch.
[CAUSE]
Although the patch I sent to the mail list doesn't change the output at
all but only a timing change, David uses this patch to unify the output
of "btrfs subvolume create" and "btrfs subvolume snapshot".
Unfortunately this changes the output and causes mismatch with
golden output.
[FIX]
Just use the recommended way to run simple btrfs command, _btrfs, for
those all "btrfs subvolume snapshot" call sites, and remove the line
from golden output.
The only case not utilizing `_btrfs` is btrfs/300, which utilize
user_do(), which doesn't have the fstests functions.
The "_btrfs()" helper has the following advantages:
- Save the command line arguments and output into $seqres.full
For easier debugging
- Check the return value of the btrfs command
This would ensure future informative output change would not trigger
such situation any more.
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>
|
|
For simple btrfs commands like "btrfs subvolume create", the output is
only informative, meanwhile the output format may still change in the
future.
Normally we already have quite some test cases just redirect the output
for null or seqres.full, without knowing we have a better suitable
function `_run_btrfs_util_prog()` already.
This patch firstly rename the function to a much shorter name `_btrfs`,
then move it to the top of `common/btrfs`, and add a comment
recommending to use it when possible.
The use of `_btrfs` mostly matches the real world usage of btrfs-progs
(just "btrfs" command), and no need to do any filtering or redirection,
and would be the recommended way for future test cases.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Remove comments from the new test template that are not relevant once
the test case is written:
- commented out common.filters (no filters used)
- Import common functions.
- real QA test starts here
- Modify as appropriate.
- get standard environment, filters and checks
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Use SCRATCH_DEV_NAME[n] to provide the device path for each device from
the scratch device pool. Also, in btrfs/197, remove common/filter since
it calls common/filter.btrfs.
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Tests btrfs/197, btrfs/198, and btrfs/297 test multiple raid types in
their workout() function. We may not support some of the raid types, so
add a check in the workout() function to skip any incompatible raid
profiles.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
In btrfs there's a few ways we limit the RAID profiles we'll use. We
have the raid56 feature that can be compiled out, zoned devices don't
support certain raid configurations, and you can manually set
BTRFS_PROFILE_CONFIGS to limit what you're testing.
To handle all of these different scenarios in the same way, update
_btrfs_get_profile_configs() to check for RAID56 support and remove it
if it is not there, and then add _require_btrfs_raid_type and
_check_btrfs_raid_type to get all the settings and then check if the
requested raid type is available.
>From there I've updated all of the existing tests that use
_require_btrfs_fs_feature raid56
to use
_require_btrfs_raid_type <type>
where appropriate.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Both btrfs/197 and btrfs/198 check several raid types. We may not have
support for raid5/6 for our available profiles, but we'd like to be able
to test the other profiles. In order to enable this, update the golden
output to have no output, and simply have the test check for the device
we removed to see if it still exists in the device list output. This
will allow us to add a check to skip unsupported raid configurations in
our config.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
It is possible to confuse the btrfs device cache (fs_devices) by
starting with a multi-device filesystem, then removing and re-adding a
device in a way which changes its dev_t while the filesystem is
unmounted. After this procedure, if we remount, then we are in a funny
state where struct btrfs_device's "devt" field does not match the bd_dev
of the "bdev" field. I would say this is bad enough, as we have violated
a pretty clear invariant.
But for style points, we can then remove the extra device from the fs,
making it a single device fs, which enables the "temp_fsid" feature,
which permits multiple separate mounts of different devices with the
same fsid. Since btrfs is confused and *thinks* there are different
devices (based on device->devt), it allows a second redundant mount of
the same device (not a bind mount!). This then allows us to corrupt the
original mount by doing stuff to the one that should be a bind mount.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ use _create_loop_device, renamed $MNT $BIND and rm them before mkdir ]
Signed-off-by: Zorro Lang <zlang@kernel.org>
[ update the commit id of _fixed_by_kernel_commit ]
|
|
Add a _require_xfs_nocrc helper that checks that we can mkfs and mount
a crc=0 file systems before running tests that rely on it to avoid failures
on kernels with CONFIG_XFS_SUPPORT_V4 disabled.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Move the subtests that check we can't upgrade v4 file systems to a
separate test.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Split the v4-specific tests into a new xfs/613.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Move the v4-specific test into a separate test case so that we can still
run the tests on a kernel without v4 support.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
xfs_db can change UUIDs on v5 filesystems now, so we don't need the
-mcrc=0 in this test.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Previously, in f2fs, sysfile quota feature has different name:
- "quota" in mkfs.f2fs
- and "quota_ino" in dump.f2fs
Now, it has unified the name to "quota" since commit 92cc5edeb7
("f2fs-tools: reuse feature_table to clean up print_sb_state()").
It needs to update keywords "quota" in _require_prjquota() for f2fs,
Otherwise, quota testcase will fail as below.
generic/383 1s ... [not run] quota sysfile not enabled in this device /dev/vdc
This patch keeps keywords "quota_ino" in _require_prjquota() to
keep compatibility for old f2fs-tools.
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Chao Yu <chao@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The following hint is added to reflect that any old kernel
without kernel commit dacfd001eaf2 (“fs/mnt_idmapping.c: Return
-EINVAL when no map is written”) is expected to fail this generic
645 test since without that commit, mount_setattr won’t return
EINVAL when attempting to create an idmapped mount using a user
namespace with no mappings.
Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Taylor Jackson <tjackson9431@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test tries to mount with same mount options on two different
mount points.
Overlayfs does not support doing that.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Replace crc as the main test feature with reflink so that this test
do not require v4 file system support.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
512 byte block sizes are only supported for v4 file systems, and
xfs/078 crudely forces use of v4 file systems for it. This doesn't
work if the kernel is built without v4 support. Given that v4
support is slowly being phased out and 512 byte block sizes have never
been common, drop this part of the test.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test exercises mkfs error handling before strict validation was added
and thus is useless for xfsprogs > 4.5.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
v5 file systems have been the default for more than 10 years. Drop
support for non-v5 enabled kernels and xfsprogs.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Creating an ext4 filesystem using '-O journal' will fail with:
Invalid filesystem option set: journal
Fix it by replacing it by '-O has_journal', which ensures the filesystem
(ext3 or ext4) is created with a journal. While there, also redirect stderr
and stdout to the full log.
Signed-off-by: "Luis Henriques (SUSE)" <luis.henriques@linux.dev>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Certain helper functions and the testcase btrfs/132 use the following
script to find running processes:
while ps aux | grep "balance start" | grep -qv grep; do
<>
done
Instead, using pgrep is more efficient.
while pgrep -f "btrfs balance start" > /dev/null; do
<>
done
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
killed/interrupted
Test cases btrfs/06[0-9] and btrfs/07[0-4] exercise multiple concurrent
operations while fsstress is running in parallel, and all these are left
as child processes running in the background, which are correctly stopped
if the tests are not interrupted/killed. However if any of these tests is
interrupted/killed, it often leaves child processes still running in the
background, which prevent further running fstests again. For example:
$ /check -g auto
(...)
btrfs/060 394s ... 264s
btrfs/061 83s ... 69s
btrfs/062 109s ... 105s
btrfs/063 52s ... 67s
btrfs/064 53s ... 51s
btrfs/065 88s ... 271s
btrfs/066 127s ... 241s
btrfs/067 435s ... 248s
btrfs/068 161s ... ^C^C
^C
$ ./check btrfs/068
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.8.0-rc7-btrfs-next-153+ #1 SMP PREEMPT_DYNAMIC Mon Mar 4 17:19:19 WET 2024
MKFS_OPTIONS -- /dev/sdb
MOUNT_OPTIONS -- /dev/sdb /home/fdmanana/btrfs-tests/scratch_1
our local _scratch_mkfs routine ...
btrfs-progs v6.6.2
See https://btrfs.readthedocs.io for more information.
ERROR: unable to open /dev/sdb: Device or resource busy
check: failed to mkfs $SCRATCH_DEV using specified options
Interrupted!
Passed all 0 tests
In this case there was still a process running _btrfs_stress_subvolume()
from common/btrfs.
This is a bit annoying because it requires manually finding out which
process is preventing unmounting the scratch device and then properly
stop/kill it.
So fix this by adding a _cleanup() function to all these tests and then
making sure it stops all the child processes it spawned and are running
in the background.
All these tests have the same structure as they were part of the same
patchset and from the same author.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Instead of having every test case that uses _btrfs_stress_subvolume()
removing the stop file before calling that function, do the file
remove at _btrfs_stress_subvolume(). There's no point in doing it in
every single test case.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
We have this logic to stop a process running _btrfs_stress_subvolume()
spread in several test cases:
touch $stop_file
wait $subvol_pid
Add a helper to encapsulate that logic and also remove the stop file after
the process terminated as there's no point having it around anymore.
This will help to avoid repeating the same code again several times in
upcoming changes.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Killing a background process running _btrfs_stress_replace() is not as
simple as sending a signal to the process and waiting for it to die.
Therefore we have the following logic to terminate such process:
kill $pid
wait $pid
while ps aux | grep "replace start" | grep -qv grep; do
sleep 1
done
Since this is repeated in several test cases, move this logic to a common
helper and use it in all affected test cases. This will help to avoid
repeating the same code again several times in upcoming changes.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
_btrfs_stress_remount_compress
Killing a background process running _btrfs_stress_remount_compress() is
not as simple as sending a signal to the process and waiting for it to
die. Therefore we have the following logic to terminate such process:
kill $pid
wait $pid
while ps aux | grep "mount.*$SCRATCH_MNT" | grep -qv grep; do
sleep 1
done
Since this is repeated in several test cases, move this logic to a common
helper and use it in all affected test cases. This will help to avoid
repeating the same code again several times in upcoming changes.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ Restore 'wait $fsstress_pid' before 'kill $replace_pid' ]
|
|
Killing a background process running _btrfs_stress_defrag() is not as
simple as sending a signal to the process and waiting for it to die.
Therefore we have the following logic to terminate such process:
kill $pid
wait $pid
while ps aux | grep "btrfs filesystem defrag" | grep -qv grep; do
sleep 1
done
Since this is repeated in several test cases, move this logic to a common
helper and use it in all affected test cases. This will help to avoid
repeating the same code again several times in upcoming changes.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Killing a background process running _btrfs_stress_scrub() is not as
simple as sending a signal to the process and waiting for it to die.
Therefore we have the following logic to terminate such process:
kill $pid
wait $pid
while ps aux | grep "scrub start" | grep -qv grep; do
sleep 1
done
Since this is repeated in several test cases, move this logic to a common
helper and use it in all affected test cases. This will help to avoid
repeating the same code again several times in upcoming changes.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
There's no need to have an explicit scratch filesystem sync and unmount
at the of the test, as the fstests framework automatically unmounts the
filesystem and the unmount naturally syncs any data and metadata.
So remove them and update the comment to be more clear.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Now that there's a helper to kill a background process that is running
_btrfs_stress_balance(), use it in btrfs/028. It's equivalent to the
existing code in btrfs/028.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Killing a background process running _btrfs_stress_balance() is not as
simple as sending a signal to the process and waiting for it to die.
Therefore we have the following logic to terminate such process:
kill $pid
wait $pid
# Wait for the balance operation to finish.
while ps aux | grep "balance start" | grep -qv grep; do
sleep 1
done
Since this is repeated in several test cases, move this logic to a common
helper and use it in all affected test cases. This will help to avoid
repeating the same code again several times in upcoming changes.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
This is a regression test for "mm/madvise: make
MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly".
Cc: David Hildenbrand <david@redhat.com>
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>
|
|
Create the $SCRATCH_MNT/urk directory before we fill the filesystem so
that its creation won't fail and result in find spraying ENOENT errors
all over the golden output.
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 fails with the fsverity patchset because the rocompat feature
bit for verity is 0x10. The regular expression used to check if the
output is hexadecimal requires a single-digit answer, which is no longer
the case.
Fixes: 5bb78c56ef ("xfs/270: Fix ro mount failure when nrext64 option is enabled")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
On power systems with 64k block size (where default page size is 64k) we
encountered a kernel oops due to an integer overflow issue when writing
near the last logical block of a file. The allocator could allocate a
range where the end exceeds the maximum supported logical block
(UINT32_MAX), leading to a subsequent BUG_ON. This issue has been
addressed in the upstream kernel with commit 2dcf5fde6dff
("ext4: prevent the normalized size from exceeding EXT_MAX_BLOCKS").
==================================================
kernel BUG at fs/ext4/mballoc.c:4448!
Oops: Exception in kernel mode, sig: 5 [#1]
CPU: 8 PID: 2880554 Comm: xfs_io
NIP ext4_mb_use_inode_pa+0x110/0x160 [ext4]
LR ext4_mb_use_inode_pa+0xac/0x160 [ext4]
Call Trace:
ext4_mb_new_inode_pa+0x134/0x3a0 [ext4]
ext4_mb_try_best_found+0x158/0x280 [ext4]
ext4_mb_regular_allocator+0x16c/0x940 [ext4]
ext4_mb_new_blocks+0x610/0x960 [ext4]
ext4_ext_map_blocks+0x858/0xa90 [ext4]
ext4_map_blocks+0x218/0x800 [ext4]
ext4_iomap_alloc+0x10c/0x260 [ext4]
ext4_iomap_begin+0xfc/0x1f0 [ext4]
iomap_iter+0xf0/0x190
__iomap_dio_rw+0x208/0x690
iomap_dio_rw+0x20/0x80
ext4_dio_write_iter+0x210/0x4d0 [ext4]
vfs_write+0x364/0x4e0
sys_pwrite64+0xd4/0x120
system_call_exception+0x164/0x310
system_call_vectored_common+0xe8/0x278
==================================================
This test has been extended to provide a hint about the relevant fix
in case of failure.
Signed-off-by: Disha Goel <disgoel@linux.ibm.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test ext4/006 takes into account the number of lines produced by its own
output. However, changes introduced to function _scratch_fuzz_modify() by
commit 9bab148bb3c7 ("common/fuzzy: exercise the filesystem a little harder
after repairing"), modified the output. Namely, the following three lines
were removed:
echo "+++ touch ${nr} files"
echo "+++ create files"
echo "+++ remove files"
And a new one was added:
echo "+++ stressing filesystem"
However, the usage of 'fsstress' also added an extra line with:
printf("seed = %ld\n", seed);
So the delta is one line (-3 + 2).
Modify test ext4/006 to take this change into account.
Signed-off-by: "Luis Henriques (SUSE)" <luis.henriques@linux.dev>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Since commit 9bab148bb3c7 ("common/fuzzy: exercise the filesystem a little
harder after repairing") funtion _scratch_fuzz_modify() has become
xfs-specific due to the use of some functions that assume this filesytem,
namely _xfs_force_bdev() and _xfs_has_feature().
Ensure _scratch_fuzz_modify() works again with other filesystems by using
these functions only when testing xfs.
Signed-off-by: "Luis Henriques (SUSE)" <luis.henriques@linux.dev>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Btrfs had a deadlock that you could trigger by mmap'ing a large file and
using that as the buffer for fiemap. This test adds a c program to do
this, and the fstest creates a large enough file and then runs the
reproducer on the file. Without the fix btrfs deadlocks, with the fix
we pass fine.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
In kernel commit dacfd001eaf2 (“fs/mnt_idmapping.c: Return -EINVAL
when no map is written”), the behavior of mount_setattr changed to
return EINVAL when attempting to create an idmapped mount when using
a user namespace with no mappings. The following commit updates the test
to expect no mount to be created in that case. And since no mount is created,
this commit also removes the check for overflow IDs because it does not make
sense to check for overflow IDs for a mount that was not created.
Signed-off-by: Taylor Jackson <tjackson9431@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Within the vfs test for idmapped mounts, the function nested_userns()
is using an incorrect array index when attempting to set up the mapping
for the 4th nested user ns within hierarchy[4]. The correct index that
belongs to the 4th nested user ns is actually hierarchy[3].
And hierarchy[4] is reserved for the dummy entry that marks the end
of the array.
Signed-off-by: Taylor Jackson <tjackson9431@gmail.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test fails for 64k filesystem block size on a 4k PAGE_SIZE
system. Scale the `blksz` based on the filesystem block size instead of
fixing it as 64k so that we do get some iomap invalidations while doing
concurrent writes.
Cap the blksz to be at least 64k to retain the same behaviour as before
for smaller filesystem blocksizes.
This fixes the "Expected to hear about writeback iomap invalidations?"
message for 64k filesystems.
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Tested-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Sometimes I hit below errors:
./common/rc: line 1293: _xfs_repair_test_fs: command not found
./common/rc: line 1298: _xfs_repair_test_fs: command not found
The _repair_test_fs trys to call _xfs_repair_test_fs(), but there's
not that function in fstests. According to commit c7d81cdecbef,
it brought in _test_xfs_repair, but called wrong name. So fix it.
Fixes: c7d81cdecbef ("check: try to fix the test device if it gets corrupted")
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
You can specify a custom BTRFS_PROFILE_CONFIGS to skip certain raid
configurations in the tests, however btrfs/195 doesn't honor this
currently. Fix this up by getting the profile configs and skipping any
configurations that are not listed in BTRFS_PROFILE_CONFIGS.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
When a dm Flakey device is configured, (or similar dm where both physical
and dm devices are accessible) we have access to both the physical device
and the dm flakey device, ensure that the physical device mount fails.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
The path /tmp.repair would be on the system root that could not be
writable, the temporary files are available at $tmp .
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Btrfs has had the ability for almost a decade to allow ro and rw
mounting of subvols. This behavior specifically
mount -o subvol=foo,ro /some/dir
mount -o subvol=bar,rw /some/other/dir
This seems simple, but because of the limitations of how we did mounting
in ye olde days we would mark the super block as RO and the mount if we
mounted RO first. In the case above /some/dir would instantiate the
super block as read only and the mount point. So the second mount
command under the covers would convert the super block to RW, and then
allow the mount to continue.
The results were still consistent, /some/dir was still read only because
the mount was marked read only, but /some/other/dir could be written to.
This is a test to make sure we maintain this behavior, as I almost
regressed this behavior while converting us to the new mount API.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ Fixed mkfs.btrfs redirect. Removed common/filter. ]
|
|
A new disk format option will make the no-holes option a requirement, so
add a helper to make sure that we aren't creating a fs with
BLOCK_GROUP_TREE by default, and skip the tests that require turning off
no-holes.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
btrfs/316 is broken on the squota configuration because it uses a raw
rescan call which fails, instead of using the rescan wrapper. The test
passes with squota, so run it (instead of requiring rescan) though I
suspect it isn't the most meaningful test.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
This test uses btrfs send with fs-verity which relies on protocol
version 3. The default in progs is version 2, so we need to explicitly
specify the protocol version. Note that the max protocol version in
progs is also currently broken (not properly gated by EXPERIMENTAL) so
that needs fixing as well.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ added _require_btrfs_send_version 3 ]
|
|
This test makes assumptions about the shared usage under snapshots which
are not valid when using squotas. Skip squotas for this test.
Also, make it use the rescan wrapper, just for uniformity and since it
doesn't hurt.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ added _require_qgroup_rescan ]
|
|
Rename _require_btrfs_send_v2() to _require_btrfs_send_version() and
check if the Btrfs kernel supports the v3 stream.
Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Some tests are still using a 'xxx...' commit ID but the respective patches
were already merged to Linus' tree or btrfs-progs, so update them with the
correct commit IDs and in two cases update the subject as well, because it
was modified after the test case was added and before being sent to Linus
(btrfs/317 and generic/707).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Don't fail this test just because the mmap read of a corrupt verity file
causes xfs_io to segfault and then dump core.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There's a bunch of tests that fail the formatting step when the test run
is configured to use XFS with a 64k blocksize. This happens because XFS
doesn't really support that combination due to minimum log size
constraints. Fix the test to format larger devices in that case.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Co-developed-by: Pankaj Raghav <p.raghav@samsung.com>
Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
If kernel supports io_uring, userspace still can/might disable that
supporting by set /proc/sys/kernel/io_uring_disabled=2. Let's notrun
if io_uring is disabled by that way.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I found the io_uring testing still fails as:
io_uring_queue_init failed
even if kernel supports io_uring feature.
That because of the /proc/sys/kernel/io_uring_disabled isn't 0.
Different value means:
0 All processes can create io_uring instances as normal.
1 io_uring creation is disabled (io_uring_setup() will fail with
-EPERM) for unprivileged processes not in the io_uring_group
group. Existing io_uring instances can still be used. See the
documentation for io_uring_group for more information.
2 io_uring creation is disabled for all processes. io_uring_setup()
always fails with -EPERM. Existing io_uring instances can still
be used.
So besides the CONFIG_IO_URING kernel config, there's another switch
can on or off the io_uring supporting. And the "2" or "1" might be
the default on some systems.
On this situation the io_uring_queue_init returns -EPERM, so I change
the fsstress to ignore io_uring testing if io_uring_queue_init returns
-ENOSYS or -EPERM. And print different verbose message for debug.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
|
|
As the manual of io_uring_queue_init says "io_uring_queue_init(3)
returns 0 on success and -errno on failure". We should check if the
return value is -ENOSYS, not the errno.
Fixes: d15b1721f284 ("ltp/fsstress: don't fail on io_uring ENOSYS")
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
|
|
st_blocks is a rather vaguely defined field. To quote the Linux stat(2)
man page:
Use of the st_blocks and st_blksize fields may be less portable.
(They were introduced in BSD. The interpretation differs between
systems, and possibly on a single system when NFS mounts are
involved.)
or the FreeBSD one:
st_blocks Actual number of blocks allocated for the file in
512-byte units. As short symbolic links are stored in
the inode, this number may be zero.
and at least for XFS they include speculative preallocations and
in-flight COW fork allocations, and the numbers can change when the way
how data is stored is reorganized. Because of that it doesn't make sense
to require st_blocks to not change after a crash even when fsync or
fdatasync was involved.
Remove the st_blocks checks and the now superfluous XFS always_cow
workaround.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Because block group tree requires require no-holes feature,
_log_writes_mkfs "-O ^no-holes" fails when "-O block-group-tree" is
given in MKFS_OPTION.
Without explicit _log_writes_cleanup, the two tests fail with
logwrites-test device left. And all next tests will fail due to
SCRATCH DEVICE EBUSY.
Fix it by overriding _cleanup to call _log_writes_cleanup.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Su Yue <glass.su@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
[BUG]
After incoming kernel commit "btrfs: qgroup: verify btrfs_qgroup_inherit
parameter", test case btrfs/121 would fail like this:
btrfs/121 1s ... [failed, exit status 1]- output mismatch (see /xfstests/results//btrfs/121.out.bad)
--- tests/btrfs/121.out 2022-05-11 09:55:30.739999997 +0800
+++ /xfstests/results//btrfs/121.out.bad 2024-03-03 13:33:38.076666665 +0800
@@ -1,2 +1,3 @@
QA output created by 121
-Silence is golden
+failed: '/usr/bin/btrfs subvolume snapshot -i 1/10 /mnt/scratch /mnt/scratch/snap1'
+(see /xfstests/results//btrfs/121.full for details)
...
(Run 'diff -u /xfstests/tests/btrfs/121.out /xfstests/results//btrfs/121.out.bad' to see the entire diff)
[CAUSE]
The incoming kernel commit would do early qgroups validation before
subvolume/snapshot creation, and reject invalid qgroups immediately.
Meanwhile that test case itself still assume the ioctl would go on
without any error, thus the new behavior would break the test case.
[FIX]
Instead of relying on the snapshot creation ioctl return value, we just
completely ignore the output of that snapshot creation.
Then manually check if the fs is still read-write.
For different kernels (3 cases), they would lead to the following
results:
- Older unpatched kernel
The filesystem would trigger a transaction abort (would be caught by
dmesg filter), and also fail the "touch" command.
- Older but patched kernel
The filesystem continues to create the snapshot, while still keeps the
fs read-write.
- Latest kernel with qgroup validation
The filesystem refuses to create the snapshot, while still keeps the
fs read-write.
Both "older but patched" and "latest" kernels would still pass the test
case, even with different behaviors.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Give them the executable permission, this also make the git status keep clean
after `./check`
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Since kernel commit a951104333bd ("dm error: Add support for zoned block
devices") dm-error fully supports zoned devices. Make use of that to
also run error injection tests for zoned device.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
xfs_db fails to properly detect the device sector size and thus segfaults
when run again an image file with 4k sector size. While that's something
we should fix in xfs_db it will require a fair amount of refactoring of
the libxfs init code. For now just change shared/298 to run xfs_db
against the loop device created on the image file that is used for I/O,
which feels like the right thing to do anyway to avoid cache coherency
issues.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
In general calling fs tools is best done on the block device used for
the file system and not the backing device of a loop file. Thus switch
shared/298 to call all fs commands on the loop device. Also add a
common on why the xfs_io fiemap command is called on the backing file,
and to have a good place for the comment stop passing the backing file
as the argument to get_holes function and just use it implicitly as
the other helpers to with the loop device.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
In some distributions, __u64 is already defined in system header files,
causing compilation errors when building xfstest.
# make
[CC] ext4_resize
ext4_resize.c:17:28: error: conflicting types for '__u64'
typedef unsigned long long __u64;
^~~~~
In file included from /usr/include/asm/types.h:26:0,
from /usr/include/linux/types.h:5,
from /usr/include/linux/mount.h:4,
from /usr/include/sys/mount.h:32,
from ext4_resize.c:15:
/usr/include/asm-generic/int-l64.h:30:23: note: previous declaration of '__u64' was here
typedef unsigned long __u64;
^~~~~
To address this issue, configure.ac now checks for the presence and
compilability of <linux/ext4.h>. If found and compilable, the macro
HAVE_LINUX_EXT4_H is defined. The commit also updates src/ext4_resize.c
to conditionally include <linux/ext4.h> based on the presence of the
header, ensuring compatibility with systems where ext4.h is either
present or not. Also include <linux/types.h> which gets __u64
definition on systems where ext4.h is not present. This change
enhances the configure process and improves code consistency.
The changes were tested on various distributions on Power
architecture, by successfully compiling xfstest. Additionally,
verified the compatibility by running ext4/033 and ext4/056
tests, both of which use ext4_resize and observed successful
test execution.
# make
checking linux/ext4.h usability... yes
checking linux/ext4.h presence... yes
checking for linux/ext4.h... yes
[CC] detached_mounts_propagation
[CC] ext4_resize
[CC] t_readdir_3
# make
checking linux/ext4.h usability... no
checking linux/ext4.h presence... no
checking for linux/ext4.h... no
[CC] detached_mounts_propagation
[CC] ext4_resize
[CC] t_snapshot_deleted_subvolume
Signed-off-by: Disha Goel <disgoel@linux.ibm.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
On a higly fragmented filesystem a Direct IO write can fail with -ENOSPC error
even though the filesystem has sufficient number of free blocks.
This occurs if the file offset range on which the write operation is being
performed has a delalloc extent in the cow fork and this delalloc extent
begins much before the Direct IO range.
In such a scenario, xfs_reflink_allocate_cow() invokes xfs_bmapi_write() to
allocate the blocks mapped by the delalloc extent. The extent thus allocated
may not cover the beginning of file offset range on which the Direct IO write
was issued. Hence xfs_reflink_allocate_cow() ends up returning -ENOSPC.
This test addresses this issue.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
These three tests examine two things -- first, can xfs CoW staging
extent recovery handle corruptions in the refcount btree gracefully; and
second, can we avoid leaking incore inodes and dquots.
The only cheap way to check the second condition is to rmmod and
modprobe the XFS module, which triggers leak detection when rmmod tears
down the caches. Currently, the entire test is _notrun if module
reloading doesn't work.
Unfortunately, these tests never run for the majority of XFS developers
because their testbeds either compile the xfs kernel driver into vmlinux
statically or the rootfs is xfs so the module cannot be reloaded. The
author's testbed boots from NFS and does not have this limitation.
Because we've had repeated instances of CoW recovery regressions not
being caught by testing until for-next hits my machine, let's make the
module reloading optional in all three tests to improve coverage.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Update this test to check that the ondisk unions for rt bitmap word and
rt summary counts are always the correct 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>
|
|
Luis Chamberlain reported insane runtimes in this test:
"xfs/599 takes a long time on LBS, but it passes. The amount of time it
takes, however, begs the question if the test is could be trimmed to do
less work because the larger the block size the larger the number of
dirents and xattrs are used to create. The large dirents are not a
problem. The amount of time it takes to create xattrs with hashcol
however grows exponentially in time.
"n=16k takes 5 seconds
"n=32k takes 30 seconds
"n=64k takes 6-7 minutes
"n=1048576 takes 30 hours
"n=1048576 is what we use for block size 32k.
"Do we really need so many xattrs for larger block sizes for this test?"
No, we don't. The goal of this test is to create a two-level dabtree of
xattrs having identical hashes. However, the test author (me)
apparently forgot that if a dabtree is created in the attr fork, there
will be a dabtree entry for each extended attribute, not each attr leaf
block. Hence it's a waste of time to multiply da_records_per_block by
attr_records_per_block.
Reported-by: Luis Chamberlain <mcgrof@kernel.org>
Fixes: 1cd6b61299 ("xfs: add a couple more tests for ascii-ci problems")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Bump the read timeout in this test to a few seconds just in case it
actually takes the IO system more than a second to retrieve the data
(e.g. cloud storage network lag).
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I have a theory that when the nfs server that hosts the root fs for my
testing VMs gets backed up, it can take a while for path resolution and
loading of echo, cat, or tee to finish. That delays the test enough to
result in:
--- /tmp/fstests/tests/generic/192.out 2023-11-29 15:40:52.715517458 -0800
+++ /var/tmp/fstests/generic/192.out.bad 2023-12-15 21:28:02.860000000 -0800
@@ -1,5 +1,6 @@
QA output created by 192
sleep for 5 seconds
test
-delta1 is in range
+delta1 has value of 12
+delta1 is NOT in range 5 .. 7
delta2 is in range
Therefore, invoke all these utilities with --help before the critical
section to make sure they're all in memory.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There are a few hard to reproduce bugs in xfs_repair where it can
deadlock trying to lock a buffer that it already owns. These stalls
cause fstests never to finish, which is annoying! To fix this, set up
the xfs_repair run to abort after 10 minutes, which will affect the
golden output and capture a core file.
This doesn't fix xfs_repair, obviously.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test will occasionaly fail like so:
--- /tmp/fstests/tests/generic/604.out 2024-02-03 12:08:52.349924277 -0800
+++ /var/tmp/fstests/generic/604.out.bad 2024-02-05 04:35:55.020000000 -0800
@@ -1,2 +1,5 @@
QA output created by 604
-Silence is golden
+mount: /opt: /dev/sda4 already mounted on /opt.
+ dmesg(1) may have more information after failed mount system call.
+mount -o usrquota,grpquota,prjquota, /dev/sda4 /opt failed
+(see /var/tmp/fstests/generic/604.full for details)
As far as I can tell, the cause of this seems to be _scratch_mount
getting forked and exec'd before the backgrounded umount process has a
chance to enter the kernel. When this occurs, the mount() system call
will return -EBUSY because this isn't an attempt to make a bind mount.
Slow things down slightly by stalling the mount by 10ms.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/022 currently fails if you are testing with -o compress because it
does a limit exceed test which will pass with compression on.
However the other functionality this test tests is completely acceptable
with compression enabled. Handle this by breaking the test into two
tests, one that simply tests the qgroup exceed limits test that requires
no compression, and the rest of the tests that do not have the no
compression restriction.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
LVM doesn't like it when you remove the file out from underneath the
backing device.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
Some of our btrfs subvolume delete calls get put into the golden output,
and many of them simply _filter_scratch. This works fine, but we
recently changed btrfs subvolume delete output, and it would have been
nice to simply filter this in one place. We have a
_filter_btrfs_subvol_delete helper, but it's only used in one place.
Fix all of these uses to call _filter_btrfs_subvol_delete, this will
allow for follow up fixes against _filter_btrfs_subvol_delete itself to
deal with changed output.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
btrfs/271 was failing with the subpage blocksize VM's. This is because
there's an assumption made that the device error counters are
per-sector, but they're per-io. With a 16kib pagesize and a 4k
sectorsize/nodesize the threshold was expecting 16 failed IO's, but
instead we were getting 5.
This other gotcha here is that with the tree log we will write the log
tree first, and then update the log root tree with the location of the
log tree root node. With pagesize == nodesize this is fine, we will
only write the log tree root node. However with subpage blocksize both
of these nodes could be on the same page, and thus they are both written
out during that initial write. When we update the pointer for the log
root tree we will COW the log root tree root node and submit another IO,
resulting in 3 metadata IO's instead of 2.
Fix the failure case to be < 4 blocks, which is the minimum number of
IO's we should be seeing.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
This test will write for 8 seconds and then try to balance, but for some
setups 8 seconds may be enough to fill the disk. Instead figure out
what half the size of the disk is and write at most that many bytes, or
for 8 seconds, whichever comes first. Then use the amount of time it
took to do the write to determine how long we should allow the balance
to continue before we attempt to cancel it.
Additionally the macro is '_notrun' not '_not_run'. With this change
this test now does the correct thing on my ARM CI VM.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
This test requires a feature that is incompatible with subpage
blocksizes. Check to see if that's what we're testing and simply skip
this test.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
/lib/modules/$(uname -r)/ can have symlinks to the source tree where the
kernel was built from, which can have all sorts of stuff, which will
make the runtime for this test exceedingly long. We're just trying to
copy some data into our tree to test with, we don't need the entire
devel tree of whatever we're doing. Additionally VM's that aren't built
with modules will fail this test.
Update the test to use /etc, which will always exist. Additionally use
timeout just in case there's large files or some other shenanigans so
the test doesn't run forever copying large amounts of files.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ fix use $TIMEOUT_PROG ]
|
|
This test exercises the btrfs replace cancel path, but in order to do
this we have to have enough work to do in order to successfully cancel
the balance, otherwise the test fails because the operation has
completed before we're able to cancel. This test has a very low pass
rate because we do not generate a large enough file system for replace
to have enough work, passing around 5% of the time. Increase the time
spent to 10x the time we wait for the replace to start its work before
we cancel, this allows us to consistently pass this test.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
The current _notrun call states that the scratch device is too small but
does not specify the required size. Simply update the _notrun messages.
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
When running _require_btrfs_mkfs_uuid_option(), some grep versions
complain about escaping the dash characters and make the tests that
use this function fail like this:
btrfs/313 2s - output mismatch (see /root/fstests/results//btrfs_normal/btrfs/313.out.bad)
--- tests/btrfs/313.out 2024-03-05 18:48:34.929372495 +0000
+++ /root/fstests/results//btrfs_normal/btrfs/313.out.bad 2024-03-05 20:52:27.745166101 +0000
@@ -1,5 +1,8 @@
QA output created by 313
---- clone_uuids_verify_tempfsid ----
+grep: warning: stray \ before -
+grep: warning: stray \ before -
+grep: warning: stray \ before -
Mounting original device
On disk fsid: FSID
...
(Run 'diff -u /root/fstests/tests/btrfs/313.out /root/fstests/results//btrfs_normal/btrfs/313.out.bad' to see the entire diff)
btrfs/314 3s - output mismatch (see /root/fstests/results//btrfs_normal/btrfs/314.out.bad)
--- tests/btrfs/314.out 2024-03-05 18:48:34.929372495 +0000
+++ /root/fstests/results//btrfs_normal/btrfs/314.out.bad 2024-03-05 20:52:32.880237216 +0000
@@ -1,6 +1,9 @@
QA output created by 314
From non-tempfsid SCRATCH_MNT to tempfsid TEST_DIR/314/tempfsid_mnt
+grep: warning: stray \ before -
+grep: warning: stray \ before -
+grep: warning: stray \ before -
wrote 9000/9000 bytes at offset 0
...
So fix this by not escaping anymore the dashes and using the -- separator
before the regex pattern parameter.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
[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>
|
