| Age | Commit message (Collapse) | Author |
|---|
|
Since commit 3687fcb0752a ("btrfs: zoned: make auto-reclaim less
aggressive"), the reclaim process won't run unless the 75% (by default) of
the filesystem volume is allocated as block groups. As a result, btrfs/237
won't success when it is run with a large volume.
To run the reclaim process, we need to either fill the FS to the desired
level, or make a small FS so that the test write can go over the level.
Since the current test code expects the FS has only one data block group,
filling the FS is both cumbersome and need effort to rewrite the test code.
So, we take the latter method. We create a small (16 * zone size) FS. The
size is chosen to hold a minimal FS with DUP metadata setup.
However, creating a small FS is not enough. With SINGLE metadata setup, we
allocate 3 zones (one for each DATA, METADATA and SYSTEM), which is less
than 75% of 16 zones. We can tweak the threshold to 51% on regular btrfs
kernel config (!CONFIG_BTRFS_DEBUG), but that is still not enough to start
the reclaim process. So, this test requires CONFIG_BTRFS_DEBUG to set the
threshold to 1%.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The "sort -R" is slower than "shuf" even with the full output because
"sort -R" actually sort them to group the identical keys.
$ time bash -c "seq 1000000 | shuf >/dev/null"
bash -c "seq 1000000 | shuf >/dev/null" 0.18s user 0.03s system 104% cpu 0.196 total
$ time bash -c "seq 1000000 | sort -R >/dev/null"
bash -c "seq 1000000 | sort -R >/dev/null" 19.61s user 0.03s system 99% cpu 19.739 total
Since the "find"'s outputs never be identical, we can just use "shuf" to
optimize the selection.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Use _random_file() helper to choose a random file in a directory.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs supports creating nesting subvolumes however snapshots are not
recurive. When a snapshot is taken of a volume which contains a subvolume
the subvolume is replaced with a stub subvolume which has the same name and
uses inode number 2. This test validates that the stub volume copies
permissions of the original volume.
Signed-off-by: Lee Trager <lee@trager.us>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The mount option "discard=async" is not meant to be used on the zoned mode.
Skip it from the test.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test is calling _not_run but it should be _notrun, so fix that.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/276 creates a 16G file with compression enabled in order to quickly
and efficiently create a file with many extents and have a fs tree with a
height of 3 (root node at level 2), so that it can test that fiemap is
correctly reporting extent sharedness when we have shared subtrees of the
fs tree due to a snapshot.
Compression results in extents with a maximum size of 128K and the test
is expecting only extents of 128K, which normally happens if the machine
has a large amount of RAM and writeback is not triggered before the xfs_io
command finishes. However if writeback is triggered in the meanwhile, due
to memory pressure for example, then we can get end up with some extents
that are smaller than 128K, therefore increasing the total number of
extents in the test file and make the test fail.
This seems to happen often on test machines with small amounts of RAM,
such as 4G, as reported by Qu in the following thread:
https://lore.kernel.org/linux-btrfs/20230801065529.50122-1-wqu@suse.com/
So to address this create a file with holes and direct IO to make sure we
always get a specific number of extents in the test file. To speedup the
test create 2000 64K extents, with holes in between them, so that it works
on a fs with any sector size, and then create a bunch of files with large
xattrs to quickly bump the fs tree height to 3 for any node size (4K to
64K). This also guarantees that the file extent items are spread over
multiples leaves, in order to exercise fiemap's correctness when reporting
shared extents due to shared subtrees.
Reported-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Tested-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There is a kernel regression caused by commit 75b470332965 ("btrfs:
raid56: migrate recovery and scrub recovery path to use error_bitmap"),
which leads to scrub not repairing corrupted parity stripes.
So here we add a test case to verify the P/Q stripe scrub behavior by:
- Create a RAID5 or RAID6 btrfs with minimal amount of devices
This means 2 devices for RAID5, and 3 devices for RAID6.
This would result the parity stripe to be a mirror of the only data
stripe.
And since we have control of the content of data stripes, the content
of the P stripe is also fixed.
- Create an 64K file
The file would cover one data stripe.
- Corrupt the P stripe
- Scrub the fs
If scrub is working, the P stripe would be repaired.
Unfortunately scrub can not report any P/Q corruption, limited by its
reporting structure.
So we can not use the return value of scrub to determine if we
repaired anything.
- Verify the content of the P stripe
- Use "btrfs check --check-data-csum" to double check
By above steps, we can verify if the P stripe is properly fixed.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test case itself is utilizing RAID5/6, which is not yet supported on
zoned device.
In the future we would use raid-stripe-tree (RST) feature, but for now
just reject zoned devices completely.
And since we're here, also update the _fixed_by_kernel_commit lines, as
the proper fix is already merged upstream.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Although btrfs has a per-fs feature directory, it's not properly
refreshed after new features are enabled.
We had some attempts to do that properly, like commit 14e46e04958d
("btrfs: synchronize incompat feature bits with sysfs files").
But unfortunately that commit get later reverted as some call sites is
not safe to update sysfs files.
Now we have a new commit b7625f461da6 ("btrfs: sysfs: update fs features
directory asynchronously") to properly refresh that per-fs features
directory.
So it's time to add a test case for it. The test case itself is pretty
straightforward:
- Make a very basic 3 disks btrfs
Only using the very basic profiles (DUP/SINGLE) so that even older
mkfs.btrfs can support.
- Make sure per-fs features directory doesn't contain "raid1c34" file
- Balance the metadata to RAID1C3 profile
- Verify the per-fs features directory contains "raid1c34" feature file
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
[ Update commit log. Remove commented code. Add _fixed_by_kernel_commit.
Check mkfs status. Add sync. ]
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
The test case would reproduce the situation by creating an empty fs,
with SINGLE metadata profile, then corrupt the tree root manually.
Finally try mounting the corrupted fs, the mount should fail while our
kernel should not fail.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
[ Update commit log. Fix a line gt 80 chars. Use append to $seqres.full.
Fix comment ]
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
There is a recent regression during v6.4 merge window, that a u32 left
shift overflow can cause problems with large data chunks (over 4G)
sized.
This is especially nasty for RAID56, which can lead to ASSERT() during
regular writes, or corrupt memory if CONFIG_BTRFS_ASSERT is not enabled.
This is the regression test case for it.
Unlike btrfs/292, btrfs doesn't support trim inside RAID56 chunks, thus
the workflow is simplified:
- Create a RAID5 or RAID6 data chunk during mkfs
- Fill the fs with 5G data and sync
For unpatched kernel, the sync would crash the kernel.
- Make sure everything is fine
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There is a recent regression during v6.4 merge window, that a u32 left
shift overflow can cause problems with large data chunks (over 4G
sized).
This is the regression test case for it.
The test case itself would:
- Create a RAID0 chunk with a single 6G data chunk
This requires at least 6 devices from SCRATCH_DEV_POOL, and each
should be larger than 2G.
- Fill the fs with 5G data
- Make sure everything is fine
Including the data csums.
- Delete half of the data
- Do a fstrim
This would lead to out-of-boundary trim if the kernel is not patched.
- Make sure everything is fine again
If not patched, we may have corrupted data due to the bad fstrim
above.
For now, this test case only checks the behavior for RAID0.
As for RAID10, we need 12 devices, which is out-of-reach for a lot of
test envionrments.
For RAID56, they would have a different test case, as they don't support
discard inside the RAID56 chunks.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test that if we have a subvolume with a non-active swap file, we can not
activate it if there are any snapshots. Also test that after all the
snapshots are removed, we will be able to activate the swapfile.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
[BUG]
Test case btrfs/106 is known to fail if the system has a page size other
than 4K.
This test case can fail like this:
btrfs/106 5s ... - output mismatch (see ~/xfstests-dev/results//btrfs/106.out.bad)
--- tests/btrfs/106.out 2022-11-24 19:53:53.140469437 +0800
+++ ~/xfstests-dev/results//btrfs/106.out.bad 2023-06-02 16:12:57.014273249 +0800
@@ -5,19 +5,19 @@
File contents before unmount:
0 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
-40
+1000
File contents after remount:
0 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
...
(Run 'diff -u ~/xfstests-dev/tests/btrfs/106.out /home/adam/xfstests-dev/results//btrfs/106.out.bad' to see the entire diff)
This is particularly problematic for systems like Aarch64 or PPC64 which
supports 64K page size.
[CAUSE]
The test case is using page size to calculate the amount of data to
write, thus it doesn't support any page sizes other than 4K.
[FIX]
Instead of using the golden output, go with md5sum and compare them
before and after the remount.
The new md5sum would only go into $seqres.full for debugging, not into
golden output to avoid false alerts on different pages sizes.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrf/122 is failing on a system with 64k page size:
QA output created by 122
+ERROR: illegal nodesize 16384 (smaller than 65536)
+mount: /mnt/scratch: wrong fs type, bad option, bad superblock on /dev/vdb2, missing codepage or helper program, or other error.
+mount /dev/vdb2 /mnt/scratch failed
+(see /xfstests-dev/results//btrfs/122.full for details)
Mkfs.btrfs sets the default node size to 16K when the sector size is less
than 16K, and it matches the sector size when it's greater than 16K.
So, there's no need to explicitly set it.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Tested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There is a regression in recent v6.4 cycle where a scrub rewrite changed
how we report errors, especially repairable errors.
Before the rewrite, we report the initial errors hit, and the amount of
repairable errors.
While after the rewrite, we no longer report the initial errors, but
only the number of repairable errors.
This behavior change is a regression, thus needs a test case to prevent
such problem from happening again.
The test case itself would:
- Create a btrfs using DUP data profile and 4K sector size
- Create a file with one 128K extent
- Corrupt the first mirror of that 128K extent
- Scrub and checks the detailed report
Both corrected errors and csum errors should be 32.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There is a regression on btrfs read-only scrub behavior.
The commit e02ee89baa66 ("btrfs: scrub: switch scrub_simple_mirror() to
scrub_stripe infrastructure") makes btrfs scrub to ignore the read-only
flag completely, causing scrub to always fix the corruption.
This test case would create an fs with repairable corruptions, then run
a read-only scrub, and finally to make sure the corruption is not
repaired.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/213 writes data, in 1M extents, for 4 seconds into a file, then
triggers a balance and then after 2 seconds it tries to cancel the
balance operation. More often than not, this works because the balance
is still running after 2 seconds. However it also fails sporadically
because balance has finished in less than 2 seconds, which is plausible
since data and metadata are cached or other factors such as virtualized
environment. When that's the case, it fails like this:
$ ./check btrfs/213
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian0 6.4.0-rc1-btrfs-next-131+ #1 SMP PREEMPT_DYNAMIC Thu May 11 11:26:19 WEST 2023
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/213 51s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/213.out.bad)
--- tests/btrfs/213.out 2020-06-10 19:29:03.822519250 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/213.out.bad 2023-05-17 15:39:32.653727223 +0100
@@ -1,2 +1,3 @@
QA output created by 213
+ERROR: balance cancel on '/home/fdmanana/btrfs-tests/scratch_1' failed: Not in progress
Silence is golden
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/213.out /home/fdmanana/git/hub/xfstests/results//btrfs/213.out.bad' to see the entire diff)
Ran: btrfs/213
Failures: btrfs/213
Failed 1 of 1 tests
To make it much less likely that balance has already finished before we
try to cancel it, unmount and mount again the filesystem before starting
balance, to clear cached metadata and data, and also double the time we
spend writing 1M data extents. Also make the test not run with an
informative message if we detect that balance finished before we could
cancel it.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The respective fix landed on kernel 6.4-rc2, commit:
0cad8f14d70c "btrfs: fix backref walking not returning all inode refs"
So update the test to include the commit hash.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a _fixed_by_kernel_commit to identify the commit the fixed the issue
the test is trying to reproduce, which was:
1dae7e0e58b4 "btrfs: reloc: clear DEAD_RELOC_TREE bit for orphan roots to prevent runaway balance"
introduced in kernel 5.8-rc1. Also remove it from the dangerous group, as
the fix is from 2020 and it was backported to stable releases.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test case btrfs/228 creates a subvolume and then calls the dump-tree
command from btrfs-progs. The tree dumping accesses the device directly
and therefore can only see committed metadata - this used to work because
subvolume creation used to commit the transaction that was used to create
the subvolume, however it is no longer the case after a recent patch that
currently is only on the btrfs integration branch "misc-next". That patch
has the following subject:
"btrfs: don't commit transaction for every subvol create"
So explicitly sync the filesystem before calling the dump-tree command,
commenting why we do it. This way the test works before and after that
patch, for any kernel release.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The top comment of test btrfs/254 mentions a kernel patch with a subject
of:
"btrfs: harden identification of the stale device"
but that is actually not correct, as the subject was slightly changed when
the patch was picked to:
"btrfs: harden identification of a stale device"
So fix that by removing the comment and use instead a call to
_fixed_by_kernel_commit, which also allows us to specify git commit id.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a 'logical_resolve' group to identify tests that use the btrfs
logical-resolve command, which exercises btrfs' logical to ino ioctl.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a test case to exercise the logical to ino ioctl, including the v2
version (which adds the ignore offset option). This is motivated by the
fact that we have no test cases giving full coverage to that ioctl, only
two test cases partially exercise it (btrfs/004 and btrfs/299) and
absolutely no coverage for the v2 ioctl. This resulted in a recent
regression fixed by the patch mentioned in the _fixed_by_kernel_commit
tag of the introduced test case.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
In upcoming changes there will be the need to find out the logical disk
address (bytenr) that a particular file extent item points to. This is
already implemented as local functions in the test btrfs/299, which is
a bit limited but works fine for that test. Some important or subtle
details why it works for this test:
1) It dumps all trees of the filesystem;
2) It relies on fsync'ing a file and then finding the desired file
extent item in the log tree from the dump;
3) There's a single subvolume, so it always finds the correct file extent
item. In case there were multiple subvolumes, it could pick the wrong
file extent item in case we have inodes with the same number on
multiple subvolumes (inode numbers are unique only within a subvolume,
they are not unique across an entire filesystem).
So add a helper to get the bytenr associated to a file extent item to
common/btrfs and use it at btrfs/299 and the upcoming changes.
This helper will dump only the tree of the default subvolume, will sync
the filesystem to commit any open transaction and works only in case the
filesystem is using the scratch device. This is explicitly documented.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
creation
[FALSE ALERT]
If test case btrfs/246 is executed with a 16K page sized system (like
some aarch64 SoCs) using 4K sector size (would be the new default), the
test case would fail with output mismatch:
btrfs/246 1s ... - output mismatch (see ~/xfstests-dev/results//btrfs/246.out.bad)
--- tests/btrfs/246.out 2022-11-24 19:53:53.158470844 +0800
+++ ~/xfstests-dev/results//btrfs/246.out.bad 2023-03-22 13:27:34.975796048 +0800
@@ -3,3 +3,5 @@
0ca3bfdeda1ef5036bfa5dad078a9f15724e79cf296bd4388cf786bfaf4195d0 SCRATCH_MNT/foobar
sha256sum after mount cycle
0ca3bfdeda1ef5036bfa5dad078a9f15724e79cf296bd4388cf786bfaf4195d0 SCRATCH_MNT/foobar
+no inline extent found
+no compressed extent found
...
(Run 'diff -u ~/xfstests-dev/tests/btrfs/246.out ~/xfstests-dev/results//btrfs/246.out.bad' to see the entire diff)
[CAUSE]
For current btrfs subpage support, there are still some limitations:
- No compressed write if the range is not fully page aligned
- No inline extents creation
Reading inline extents is still supported
Thus we won't create such inlined compressed extent at all.
[FIX]
Just skip the test case if we can not even create a regular inline
extent.
This is done by a new require helper,
_require_btrfs_inline_extent_creation(), which would detect if btrfs can
even create an uncompressed inlined extent.
Reported-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test is doing a _scratch_dev_pool_get, which shrinks the list of
devices in SCRATCH_DEV_POOL, but it's not calling _scratch_dev_pool_put
before it finishes. This will result in subsequent tests (none at the
moment however) getting a reduced list of devices in SCRATCH_DEV_POOL.
The same goes for the spare device, the test calls _spare_dev_get but
it never calls _spare_dev_put.
So add the missing calls.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test may often fail when running with btrfs-progs versions not very
recent. The corresponding git commits in btrfs-progs that fix issues
uncovered by this test are:
1) 6f4a51886b37 ("btrfs-progs: receive: fix silent data loss after fall back from encoded write")
Introduced in btrfs-progs v6.0.2;
2) e3209f8792f4 ("btrfs-progs: receive: fix a corruption when decompressing zstd extents"")
Introduced in btrfs-progs v6.2.
So add the corresponding _fixed_by_git_commit calls to the test.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
During my development on dev-replace, I made a mistake in RAID56
dev-replace code where it can lead to NODATASUM corruption.
Thankfully such corruption didn't reach upstream.
Inspired by such incident, here comes a new test case for btrfs
dev-replace, the new case would:
- Populate the filesystem with nodatasum mount option
- Run fssum to record the contents
Since the test case only cares about data contents, here we don't
include metadata like uid/gid/timestamp.
- Wipe one device
- Mount the fs with the missing device
- Verify the contents is still correct
- Replace the missing device
- Verify the contents is still correct again
Before the verification, drop all cache to make sure the 2nd
verification is reading from the disks.
For current kernels, the test case should pass as expected.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add the _wants_kernel_commit tag for kernel and _fixed_by_git_commit tag
for the btrfs-progs for the benefit of testing on the older kernels and
the older btrfs-progs.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Recently, these test cases were added to the auto group. To ensure we have
some clues if they fail in older kernels, add "_fixed_by_kernel_commit"
for the fix and update the test summary.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add a new test which checks that size classes in freshly loaded block
groups after a cycle mount match size classes before going down
Depends on the kernel patch:
btrfs: add size class stats to sysfs
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Generally the tester need BTRFS_PROFILE_CONFIGS to test certain
profeils. For example, skip raid56 as it's not supported.
For dup profile, add dup to default profile configs.
Signed-off-by: An Long <lan@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/185 runs in a second, add it to the auto and quick group.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/125 runs in 5 seconds on my VM setup, and found a regression in a
recent series. Add it to the auto and quick groups.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The quick group should be a strict subset of the auto group, so add these
two tests that are in the quick group to the auto group as well.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Currently we don't have any test case in fstests to do randomized and
stress testing of the send stream v2, added in kernel 6.0 and support for
it in btrfs-progs v5.19. For the send v2 stream, we only have btrfs/281
that exercises a specific scenario which used to trigger a bug.
So add a test that uses fsstress to generate a filesystem and exercise
both full and incremental send operations using the v2 send stream with
compressed extents, and then receive the streams without and with
decompression, to verify they work and produce the same results as in
the original filesystem. This is the same base idea as btrfs/007, but
for the send v2 stream with compressed data.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test that send operations do the best cloning decisions when we have
extents that are shared but some files refer to the full extent while
others refer to only a section of the extent.
This exercises an optimization that was added to kernel 6.2, by the
following commit:
c7499a64dcf6 ("btrfs: send: optimize clone detection to increase extent sharing")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test case btrfs/299 refers to a kernel patch with a subject of:
"btrfs: fix logical_ino ioctl panic"
However when the patch was merged, the subject was renamed to:
"btrfs: fix resolving backrefs for inline extent followed by prealloc"
So update the test with the correct subject and also add the commit's
hash from Linus' tree.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/012 is requiring ext4 support to test the conversion, but the test
case is only checking if mkfs.ext4 is available, not if the filesystem
driver is actually available on the test host.
Check if the driver is available as well, before trying to run the test.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
We introduced scrub speed throttle in commit eb3b50536642 ("btrfs: scrub:
per-device bandwidth control"), but it is not that well documented
(e.g. what's the unit of the sysfs interface), nor tested by any test
case.
This patch will add a test case for this functionality.
The test case itself is pretty straightforward:
- Fill the fs with 2G file as scrub workload
- Scrub without any throttle to grab the initial speed
- Set the throttle to half of the initial speed
- Scrub again and check the speed against the throttle
The test case has an assumption that we can exclusively use all the
performance of the underlying disk.
But for cloud environment it's not ensured 100%, thus the test case is
not included in auto group to avoid false alerts.
[zlang: add auto group, remove useless comments]
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oralce.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test case btrfs/154 is still using python2 script, which is already EOL.
Some rolling distros like Archlinux is no longer providing python2
package anymore.
This means btrfs/154 will be harder and harder to run.
To fix the problem, migreate the python script to python3, this involves
the following changes:
- Change common/config to use python3
- Strong type conversion between string and bytes
This means, anything involved in the forged bytes has to be bytes.
And there is no safe way to convert forged bytes into string, unlike
python2.
I guess that's why the author went python2 in the first place.
Thankfully os.rename() still accepts forged bytes.
- Use bytes specific checks for invalid chars.
The updated script can still cause the needed conflicts, can be verified
through "btrfs ins dump-tree" command.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
[BUG]
The latest misc-next tree will make test case btrfs/220 fail with the
following error messages:
btrfs/220 15s ... - output mismatch (see ~/xfstests/results//btrfs/220.out.bad)
--- tests/btrfs/220.out 2022-05-11 09:55:30.749999997 +0800
+++ ~/xfstests/results//btrfs/220.out.bad 2022-12-09 13:57:23.706666671 +0800
@@ -1,2 +1,5 @@
QA output created by 220
+Unexepcted mount options, checking for 'rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/' in 'rw,relatime,space_cache=v2,subvolid=5,subvol=/' using 'nodiscard'
+Unexepcted mount options, checking for 'rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/' in 'rw,relatime,space_cache=v2,subvolid=5,subvol=/' using 'nodiscard'
+Unexepcted mount options, checking for 'rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/' in 'rw,relatime,space_cache=v2,subvolid=5,subvol=/' using 'nodiscard'
Silence is golden
...
(Run 'diff -u ~/xfstests/tests/btrfs/220.out ~/xfstests/results//btrfs/220.out.bad' to see the entire diff)
Ran: btrfs/220
Failures: btrfs/220
Failed 1 of 1 tests
[CAUSE]
Since patch "btrfs: auto enable discard=async when possible", which is
already in the maintainer's tree for next merge window, btrfs will
automatically enable asynchronous discard for devices which supports
discard.
This makes our $DEFAULT_OPTS to have "discard=async" in it.
While for "nodiscard" mount option, we will completely disable all
discard, causing the above mismatch.
[FIX]
Fix it by introducing $DEFAULT_NODISCARD_OPTS specifically for
"nodiscard" mount option.
If async discard is not enabled by default, $DEFAULT_NODISCARD_OPTS will
be the same as $DEFAULT_OPTS, thus everything would work as usual.
If async discard is enabled by default, $DEFAULT_NODISCARD_OPTS will
have that removed, so for "nodiscard" we can use $DEFAULT_NODISCARD_OPTS
as expected mount options.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
If we create a file that has an inline extent followed by a prealloc
extent, then attempt to use the logical to inode ioctl on the prealloc
extent, but in the overwritten range, backref resolution will process
the inline extent. Depending on the leaf eb layout, this can panic.
Add a new test for this condition. In the long run, we can add spew when
we read out-of-bounds fields of inline extent items and simplify this
test to look for dmesg warnings rather than trying to force a fairly
fragile panic (dependent on non-standardized details of leaf layout).
The test causes a kernel panic unless:
btrfs: fix logical_ino ioctl panic
is applied to the kernel.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test case is to make sure we can mount a fs with older generation
(but with the same fsid/dev uuid).
Normally we will reject such case as btrfs is maintaining an internal
devices list (for multi-device support), and if we find a device
suddenly got an older generation, we will directly reject it.
Although for single device btrfs, we may add an exception for it,
the corresponding kernel patch is never merged.
So for now, just remove the test case from auto group.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
[BUG]
The latest grep will report stray '\', causing golden output mismatch
for btrfs/080:
btrfs/080 - output mismatch (see ~/xfstests-dev/results//btrfs/080.out.bad)
--- tests/btrfs/080.out 2022-11-24 19:53:53.137469203 +0800
+++ ~/xfstests-dev/results//btrfs/080.out.bad 2022-12-09 11:41:46.194597311 +0800
@@ -1,2 +1,3 @@
QA output created by 080
+grep: warning: stray \ before -
Silence is golden
...
(Run 'diff -u ~/xfstests-dev/tests/btrfs/080.out ~/xfstests-dev/results//btrfs/080.out.bad' to see the entire diff)
[CAUSE]
Even for regrex of grep, '-' doesn't need special escape, thus
"\bno\-holes\b" indeed has an unnecessary '\' before '-'.
[FIX]
Just remove the stray '\'.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test that if we have a snapshot with a compressed extent that is partially
shared between two files, one of them has a size that is not sector size
aligned, we create a v2 send stream for the snapshot with compressed data,
and then apply that stream to another filesystem, the operation succeeds
and no data is missing. Also check that the file that had a reference to
the whole extent gets two compressed extents in the new filesystem, with
only one of them being shared (reflinked).
This tests a recent patch that landed in kernel 6.1-rc7:
a11452a3709e ("btrfs: send: avoid unaligned encoded writes when attempting to clone range")
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Now that _filter_fiemap_flags() optionally reports the encoded flag and
since btrfs/280 explicitly uses and tests compression, make it check that
fiemap reports the compressed extents with the encoded flag set.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
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>
|
