fstests: skip btrfs/254 in case MIN_FSSIZE is more than 1G
The test-case btrfs/254 creates a 1G device-mapper setup, but this might
be too small for the filesystem to actually operate (i.e. in case of a
zoned block device which needs at least 5 zones).
Skip the test if MIN_FSSIZE is set to a value above 1G.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jan Kara [Tue, 22 Nov 2022 14:12:19 +0000 (15:12 +0100)]
generic/614: Run test only for filesystems supporting delalloc
Simple filesystems such as ext2 or udf do not support delayed
allocation. Thus they allocate data blocks for mmap writes only during
writeback. This makes test generic/614 fail because it checks exactly
whether the blocks for the write are reserved before writeback happens.
Make the test depend on delayed allocation support.
Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Zorro Lang [Tue, 8 Nov 2022 18:32:42 +0000 (02:32 +0800)]
fstests: update group name according to xfs_io command requirement
When a test case requires someone xfs_io command, that nearly means
that case belong that kind of test group. Likes fpunch for punch
group, fcollapse for collapse group, falloc for prealloc group, fzero
for zero group and so on.
Many fstests cases miss some test groups they should belong to, so
this patch trys to supplement this lack, according to the "xxxx"
which required by _require_xfs_io_command "xxxx".
Luís Henriques [Tue, 15 Nov 2022 14:45:00 +0000 (14:45 +0000)]
ceph/005: skip test if using "test_dummy_encryption"
When using the "test_dummy_encryption" mount option, new file and directory
names will be encrypted. This means that if using as a mount base directory
a newly created directory, we would have to use the encrypted directory name
instead. For the moment, ceph doesn't provide a way to get this encrypted
file name, thus for now simply skip this test.
Signed-off-by: Luís Henriques <lhenriques@suse.de> Reviewed-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Xiao Yang [Mon, 14 Nov 2022 08:35:03 +0000 (08:35 +0000)]
generic/470: Replace thin volume with blkdiscard -z
generic/470 was original designed to verify mmap(MAP_SYNC) which
is only valid to the DAX capable device(e.g. PMEM). Thin volume[1] was
introduced to fix the inconsistent filesystem issue[2] but it make
the test become not run because it doesn't support DAX. As Darrick
mentioned[3], zeroing the entire mapped range of scartch device
can fix the issue as well, so I try to use blkdiscard -z instead.
Filipe Manana [Wed, 9 Nov 2022 16:44:58 +0000 (16:44 +0000)]
btrfs: fix failure of tests that use defrag on btrfs-progs v6.0+
Starting with btrfs-progs v6.0, the defrag command now prints to stdout
the full path of the files it processes. This makes test cases btrfs/021
and btrfs/256 fail because they don't expect any output from the defrag
command.
The change happened with the following commit in btrfs-progs:
dd724f21803d ("btrfs-progs: add logic to handle LOG_DEFAULT messages")
So update the tests to ignore the stdout of the defrag command.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Wed, 9 Nov 2022 16:44:57 +0000 (16:44 +0000)]
btrfs/053: fix test failure when running with btrfs-progs v6.0+
In btrfs-progs v6.0 the --leafsize (-l) command line option was removed
from mkfs.btrfs, so btrfs/053 can fail with v6.0+ in case the scratch
device does not have a btrfs filesystem created before running the test,
in which case mounting the scratch device fails.
The change was introduced by the following btrfs-progs commit:
f7a768d62498 ("btrfs-progs: mkfs: remove support for option --leafsize")
Change the test to use --nodesize (-n) instead, since it exists in both
old and new btrfs-progs versions. Also redirect mkfs output to the test's
log file and fail explicitly if mkfs failed.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Wed, 9 Nov 2022 16:44:56 +0000 (16:44 +0000)]
btrfs/003: fix failure on new btrfs-progs versions
Starting with btrfs-progs version 5.19, the output of 'filesystem show'
command changed when we have a missing device. The old output was like the
following:
Label: none uuid: 139ef309-021f-4b98-a3a8-ce230a83b1e2
Total devices 2 FS bytes used 128.00KiB
devid 1 size 5.00GiB used 1.26GiB path /dev/loop0
*** Some devices missing
While the new output (btrfs-progs 5.19+) is like the following:
Label: none uuid: 4a85a40b-9b79-4bde-8e52-c65a550a176b
Total devices 2 FS bytes used 128.00KiB
devid 1 size 5.00GiB used 1.26GiB path /dev/loop0
devid 2 size 0 used 0 path /dev/loop1 MISSING
More specifically it happened in the following btrfs-progs commit:
957a79c9b016 ("btrfs-progs: fi show: print missing device for a mounted file system")
This is making btrfs/003 fail with btrfs-progs 5.19+. Update the grep
filter in btrfs/003 so that it works with both output formats.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
[FAILURES]
The following btrfs test cases failed with newer btrfs-progs:
- btrfs/197
- btrfs/198
- btrfs/254
They all fail due to output mismatch like the following:
Label: none uuid: <UUID>
Total devices <NUM> FS bytes used <SIZE>
devid <DEVID> size <SIZE> used <SIZE> path SCRATCH_DEV
- *** Some devices missing
+ devid <DEVID> size 0 used 0 path MISSING
[CAUSE]
Since btrfs-progs commit 957a79c9b016 ("btrfs-progs: fi show: print
missing device for a mounted file system"), we output the detailed info
of a missing device if "btrfs filesystem show" is executed using
"-m <mnt>" option.
Such detailed output no longer follows the old format, thus causing the
output mismatch.
[FIX]
Update _filter_btrfs_filesystem_show() to handle detailed missing
device by:
- Buffer the output first
- Output the first two lines
Which is always label/uuid and the total device accounting.
- Replace the detailed missing device line with old output
- Sort (in reverse order) and uniq the device list
By this we can handle both old and new output correctly.
Although this means we lacks the ability to detect mutltiple missing
devices, thankfully the involved test cases are not checking this yet.
[ Zorro: add "rm -f $tmp.btrfs_filesystem_show" ]
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Zorro Lang [Wed, 9 Nov 2022 13:07:46 +0000 (21:07 +0800)]
generic: shutdown might leave NULL files with nonzero di_size
An old issue might cause on-disk inode sizes are logged prematurely
via the free eofblocks path on file close. Then fs shutdown might
leave NULL files but their di_size > 0.
Signed-off-by: Zorro Lang <zlang@kernel.org> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Mon, 7 Nov 2022 09:38:58 +0000 (09:38 +0000)]
generic: check direct IO writes with io_uring and O_DSYNC are durable
Test that direct IO writes with io_uring and O_DSYNC are durable if a
power failure happens after they complete.
This is motivated by a regression on btrfs, affecting 5.15 stable
kernels and kernels up to 6.0, where often the writes were not
persisted (same behaviour as if O_DSYNC was not provided). This was
recently fixed by the following commit:
8184620ae212 ("btrfs: fix lost file sync on direct IO write with
nowait and dsync iocb")
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Whitney [Fri, 21 Oct 2022 21:19:50 +0000 (17:19 -0400)]
generic: add missing $FSX_AVOID to fsx invocations
generic/455 fails when run on an ext4 bigalloc file system. Its
fsx invocations can make insert range and collapse range calls whose
arguments are not cluster aligned, and ext4 will fail those calls for
bigalloc. They can be suppressed by adding the FSX_AVOID environment
variable to the fsx invocation and setting its value appropriately in
the test environment, as is done for other fsx-based tests. This
avoids the need to exclude the test to avoid failures and makes it
possible to take advantage of the remainder of its coverage.
[ Also fix generic/457, as requested by Dave Chinner -- TYT]
Signed-off-by: Eric Whitney <enwlinux@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Fri, 4 Nov 2022 20:58:30 +0000 (13:58 -0700)]
tests: fix some tests for systems with fs.verity.require_signatures=1
Some of the newer verity tests don't work properly on systems where
fs.verity.require_signatures is enabled, either because they forget to
disable it at the beginning of the test, or they forget to re-enable it
afterwards, or both. Fix this.
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Fri, 4 Nov 2022 20:58:29 +0000 (13:58 -0700)]
generic/577: add missing file removal before empty file test
The fix for _fsv_have_hash_algorithm() exposed a bug where one of the
test cases in generic/577 isn't deleting the file from the previous test
case before it tries to write to it. That causes a failure, since due
to the fix for _fsv_have_hash_algorithm(), the file from the previous
test case now ends up with verity enabled and therefore cannot be
written to. Fix this by deleting the file.
Reported-by: Andrey Albershteyn <aalbersh@redhat.com> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Fri, 4 Nov 2022 20:58:28 +0000 (13:58 -0700)]
common/verity: fix _fsv_have_hash_algorithm() with required signatures
_fsv_have_hash_algorithm() uses _fsv_enable() without a signature, so it
always fails when called while fs.verity.require_signatures=1. This
happens in generic/577, which tests file signing. This wasn't noticed
because it just made part of generic/577 always be skipped.
Fix this by making _fsv_have_hash_algorithm() temporarily set
fs.verity.require_signatures to 0.
Since the previous value needs to be restored afterwards, whether it is
0 or 1, also make some changes to the fs.verity.require_signatures
helper functions to allow the restoration of the previous value, rather
than the value that existed at the beginning of the test.
Finally, make a couple related cleanups: make _fsv_have_hash_algorithm()
always delete the file it works with, and also update the similar code
in _require_scratch_verity().
Reported-by: Andrey Albershteyn <aalbersh@redhat.com> Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Thu, 3 Nov 2022 04:17:06 +0000 (21:17 -0700)]
xfs: test xfs_scrub phase 6 media error reporting
Add new helpers to dmerror to provide for marking selected ranges
totally bad -- both reads and writes will fail. Create a new test for
xfs_scrub to check that it reports media errors in data files correctly.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Mon, 31 Oct 2022 11:11:21 +0000 (11:11 +0000)]
btrfs: test fiemap reports extent as not shared after COWing it in snapshot
Test that if we have a large file, with file extent items spanning several
leaves in the fs tree, and that is shared due to a snapshot, if we COW one
of the extents, doing a fiemap will report the respective file range as
not shared.
This exercises the processing of delayed references for metadata extents
in the backref walking code, used by fiemap to determine if an extent is
shared.
This used to fail until very recently and was fixed by the following
kernel commit that landed in 6.1-rc2:
943553ef9b51 (""btrfs: fix processing of delayed tree block refs during backref walking")
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Mon, 31 Oct 2022 11:11:20 +0000 (11:11 +0000)]
btrfs: test that fiemap reports extent as not shared after deleting file
Test that if we have two files with shared extents, after removing one of
the files, if we do a fiemap against the other file, it does not report
extents as shared anymore.
This exercises the processing of delayed references for data extents in
the backref walking code, used by fiemap to determine if an extent is
shared.
This used to fail until very recently and was fixed by the following
kernel commit that landed in 6.1-rc2:
4fc7b5722824 (""btrfs: fix processing of delayed data refs during backref walking")
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Mon, 31 Oct 2022 11:11:19 +0000 (11:11 +0000)]
common/punch: fix flags printing for filter _filter_fiemap_flags
In the filter _filter_fiemap_flags, if we get a flags field that only has
the 'last' flag set, we end up printing the string "nonelast", which is
ugly and not intuitive.
So fix this by updating the filter's awk code to reset the flags string to
an empty string if we have the "last" flag set and we haven't updated the
flags string before. So now the same test gives the following result:
0: [0..127]: last
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Xiao Yang [Thu, 27 Oct 2022 10:50:52 +0000 (10:50 +0000)]
common/config: Make test and scratch devices use the same mount options
Some cases(e.g. generic/519) check commands/features on test device but
do tests on scratch device. If some mount options can impact the check
result, these cases may throw error instead if not run when we use
different mount options for test and scratch devices.
Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Zorro Lang [Fri, 28 Oct 2022 15:43:37 +0000 (23:43 +0800)]
xfs: new test on xfs with corrupted sb_inopblock
There's a known bug fix 392c6de98af1 ("xfs: sanitize sb_inopblock in
xfs_mount_validate_sb"). So try to corrupt the sb_inopblock of xfs,
to cover this bug.
Signed-off-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Fri, 28 Oct 2022 17:42:10 +0000 (10:42 -0700)]
common: simplify grep pipe sed interactions
Zorro pointed out that the idiom "program | grep | sed" isn't necessary
for field extraction -- sed is perfectly capable of performing a
substitution and only printing the lines that match that substitution.
Do that for the common helpers.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
There are a lot of places where we open-code detecting the realtime
extent size and extent count of a specific filesystem. Refactor this
into a couple of helpers to clean up the code.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
There are a lot of places where we open-code determining the directory
block size for a specific filesystem. Refactor this into a single
helper to clean up existing tests.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Fri, 28 Oct 2022 17:41:53 +0000 (10:41 -0700)]
xfs: refactor filesystem feature detection logic
There are a lot of places where we open-code detecting features of a
specific filesystem. Refactor this into a couple of helpers in
preparation for adding stress tests for online repair and fuzzing.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Hironori Shiina [Mon, 17 Oct 2022 15:11:51 +0000 (11:11 -0400)]
xfs: test for fixing wrong root inode number in dump
Test '-x' option of xfsrestore. With this option, a wrong root inode
number in a dump file is corrected. A root inode number can be wrong
in a dump created by problematic xfsdump (v3.1.7 - v3.1.9) with
bulkstat misuse. In this test, a corrupted dump file is created by
overwriting a root inode number in a header.
Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Hironori Shiina <shiina.hironori@fujitsu.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Josef Bacik [Wed, 24 Aug 2022 19:32:10 +0000 (15:32 -0400)]
fstests: get section config after RUN_SECTION checks
While trying to do
./check -s <some section>
I was failing because I had a section defined higher than <some section>
that had TEST_DEV=/some/nonexistent/device, since I was using the other
section to test an experimental drive. This appears to be because we
run through all of the sections, and when getting the section config we
check to see if it's valid, and in this case the section wasn't valid.
The section I was actually trying to use was valid however. Fix check
to see if the section we're trying to run is in our list of sections to
run first, and then if it is get the config at that point.
Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 12 Oct 2022 01:45:39 +0000 (18:45 -0700)]
populate: reformat external ext[34] journal devices when restoring a cached image
The fs population code has the ability to save cached metadumps of
filesystems to save time when running fstests. The cached images should
be unmounted cleanly, so we never save the contents of external journal
devices.
Unfortunately, the cache restore code fails to reset the external
journal when restoring a clean image, so we ignore cached images because
the journal doesn't match the filesystem. This makes test runtimes
longer than they need to be.
Solve this by reformatting the external journal to match the filesystem.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 12 Oct 2022 01:45:33 +0000 (18:45 -0700)]
populate: wipe external xfs log devices when restoring a cached image
The fs population code has the ability to save cached metadumps of
filesystems to save time when running fstests. The cached images should
be unmounted cleanly, so we never save the contents of external log
devices.
Unfortunately, the cache restore code fails to wipe the external log
when restoring a clean image, so we end up with strange test failures
because the log doesn't match the filesystem:
Theodore Ts'o [Thu, 13 Oct 2022 14:48:44 +0000 (10:48 -0400)]
ext4/053: remove test for i_version mount option
The i_version mount option is deprecated in favor of iversion and is
advertised to be removed in 5.20. It was removed in commit 1ff20307393e ("ext4: unconditionally enable the i_version counter") in
Linux v6.1. So remove the test from ext4/053.
Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Sat, 15 Oct 2022 04:57:05 +0000 (12:57 +0800)]
check: optionally compress core dumps
Add a new option, COREDUMP_COMPRESSOR, that will be used to compress
core dumps collected during a fstests run. The program specified must
accept the -f -9 arguments that gzip has.
Darrick J. Wong [Fri, 14 Oct 2022 18:20:20 +0000 (11:20 -0700)]
check: detect and preserve all coredumps made by a test
If someone sets kernel.core_uses_pid (or kernel.core_pattern), any
coredumps generated by fstests might have names that are longer than
just "core". Since the pid isn't all that useful by itself, let's
record the coredumps by hash when we save them, so that we don't waste
space storing identical crash dumps.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
David Disseldorp [Tue, 11 Oct 2022 09:23:39 +0000 (11:23 +0200)]
lsqa.pl: fix --header output
7e98d41a ("fstests: move test group info to test files") replaces the
post-header "seq" assignment with "./common/preamble\n_begin_fstest ..."
Update lsqa.pl to recognise the "./common/preamble" line as a header
divider.
Signed-off-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 11 Oct 2022 12:22:03 +0000 (13:22 +0100)]
generic: test fiemap reports extent as shared after cloning it
Test that if we have two consecutive extents and only one of them is
cloned, then fiemap correctly reports which one is shared and reports
the other as not shared.
This currently fails on btrfs for all kernel releases, but is fixed by
a kernel patch that landed in Linus' tree last week:
ac3c0d36a2a2f7 ("btrfs: make fiemap more efficient and accurate reporting extent sharedness")
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 7 Oct 2022 13:53:36 +0000 (14:53 +0100)]
fstests: add fiemap group
Add a fiemap group for all tests that exercise fiemap, either directly
through xfs_io, or more indirectly like through filefrag or helpers in
common/* (like _count_extents, _count_holes, etc). This is useful in
order to quickly test changes made to the fiemap implementation of a
filesystem for example.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 7 Oct 2022 13:53:35 +0000 (14:53 +0100)]
fstests: add missing require of xfs_io fiemap command to some tests
btrfs/257, btrfs/258, btrfs/259 and xfs/443 use the fiemap command of
xfs_io but don't do a '_require_xfs_io_command "fiemap"'. So add the
missing requirement.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Due to some braino on my part, _scratch_populate_cached will metadump
the filesystem twice -- once with compression disabled, and again with
it enabled, maybe. Get rid of the first metadump.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 5 Oct 2022 22:30:55 +0000 (15:30 -0700)]
xfs/128: try to force file allocation behavior
Over the years, I've noticed that this test occasionally fails when I've
programmed the allocator to hand out the minimum amount of space with
each allocation or if extent size hints are enabled:
--- /tmp/fstests/tests/xfs/128.out 2022-09-01 15:09:11.506679341 -0700
+++ /var/tmp/fstests/xfs/128.out.bad 2022-10-04 17:32:50.992000000 -0700
@@ -20,7 +21,9 @@ 56ed2f712c91e035adeeb26ed105a982 SCRATCH_MNT/test-128/file3 b81534f439aac5c34ce3ed60a03eba70 SCRATCH_MNT/test-128/file4
Check files
free blocks after creating some reflink copies is in range
free blocks after CoW some reflink copies is in range
-free blocks after defragging all reflink copies is in range
-free blocks after all tests is in range
+free blocks after defragging all reflink copies has value of 8620027
+free blocks after defragging all reflink copies is NOT in range 8651819 .. 8652139
+free blocks after all tests has value of 8620027
+free blocks after all tests is NOT in range 8651867 .. 8652187
It turns out that under the right circumstances, the _pwrite_byte at the
start of this test will end up allocating two extents to file1. This
almost never happens when delalloc is enabled or when the extent size is
large, and is more prone to happening if the extent size is > 1FSB but
small, the allocator hands out small allocations, or if writeback shoots
down pages in random order.
When file1 gets more than 1 extent, problems start to happen. The free
space accounting checks at the end of the test assume that file1 and
file4 still share the same space at the end of the test. This
definitely happens if file1 gets one extent (since fsr ignores
single-extent files), but if there's more than 1, fsr will try to
defragment it. If fsr succeeds in copying the file contents to a temp
file with fewer extents than the source file, it will switch the
contents, but unsharing the contents in the process. This cause the
free space to be lower than expected, and the test fails.
Resolve this situation by preallocating space beforehand to try to set
up file1 with a single space extent. If the test fails and we got more
than one extent, note that in the output.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 5 Oct 2022 22:30:49 +0000 (15:30 -0700)]
xfs/229: do not _xfs_force_bdev on TEST_DIR
In commit ea15099b71, I observed that this test tries to test the
behavior of the extent size hint on the data device. If the test runner
set up MKFS_OPTIONS such that the filesystem gets created with a
realtime section and rtinherit set on the root directory, then the
preconditions of this test (creating files on the data section) is not
satisfied and the results of this test are incorrect. The solution was
to force all files created by this test to be assigned to the data
section.
Unfortunately, the correction that I made has side effects beyond this
test -- by clearing rtinherit on $TEST_DIR, all tests that run after
this one will create files on the data section, because the test
filesystem persists for the duration of the entire test run. This leads
to the wrong things being tested.
Fix this new problem by clearing the rtinherit flag on $TDIR, which
contains the files created by this test and is removed during cleanup,
and leave a few comments celebrating our new discoveries.
Fixes: ea15099b71 ("xfs: force file creation to the data device for certain layout tests") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 5 Oct 2022 22:30:38 +0000 (15:30 -0700)]
generic/092: skip test if file allocation unit isn't aligned
This test exercises allocation behavior when truncating a preallocated
file down to 5M and then up to 7M. If those two sizes aren't aligned
with the file allocation unit length, then the FIEMAP output will show
blocks beyond EOF. That will cause trouble with the golden output, so
skip this test if that will be the case.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 7 Oct 2022 13:53:34 +0000 (14:53 +0100)]
btrfs: test fiemap on large file with extents shared through a snapshot
Verify that fiemap correctly reports the sharedness of extents for a file
with a very large number of extents, spanning many b+tree leaves in the fs
tree, and when the file's subvolume was snapshoted.
Currently this passes on all kernel releases and its purpose is to prevent
and detect regressions in the future, as this actually happened during
recent development on the btrfs' fiemap related code. With this test we
now have better coverage for fiemap when a file is shared through a
snapshot.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Naohiro Aota [Wed, 5 Oct 2022 05:46:44 +0000 (14:46 +0900)]
btrfs: test active zone tracking
A ZNS device limits the number of active zones, which is the number of
zones can be written at the same time. To deal with the limit, btrfs's
zoned mode tracks which zone (corresponds to a block group on the SINGLE
profile) is active, and finish a zone if necessary.
This test checks if the active zone tracking and the finishing of zones
works properly. First, it fills <number of max active zones> zones
mostly. And, run some data/metadata stress workload to force btrfs to use a
new zone.
This test fails on an older kernel (e.g, 5.18.2) like below.
btrfs/273
[failed, exit status 1]- output mismatch (see /host/btrfs/273.out.bad)
--- tests/btrfs/273.out 2022-09-15 07:52:18.000000000 +0000
+++ /host/btrfs/273.out.bad 2022-09-15 07:59:14.290967793 +0000
@@ -1,2 +1,5 @@
QA output created by 273
-Silence is golden
+stress_data_bgs failed
+stress_data_bgs_2 failed
+failed: '/bin/btrfs subvolume snapshot /mnt/scratch /mnt/scratch/snap825'
+(see /host/btrfs/273.full for details)
...
(Run 'diff -u /var/lib/xfstests/tests/btrfs/273.out /host/btrfs/273.out.bad' to see the entire diff)
The failure is fixed with a series "btrfs: zoned: fix active zone tracking
issues" [1] (upstream commits from 65ea1b66482f ("block: add bdev_max_segments()
helper") to 2ce543f47843 ("btrfs: zoned: wait until zone is finished when
allocation didn't progress")).
Naohiro Aota [Wed, 5 Oct 2022 05:46:43 +0000 (14:46 +0900)]
common: introduce zone_capacity() to return a zone capacity
Introduce _zone_capacity() to return a zone capacity of the given address
in the given device (optional). Move _filter_blkzone_report() for it, and
rewrite btrfs/237 with it.
Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
projects / xfstests-dev.git / log