This test case, btrfs/112, tests that some clone operations that have a
range covering inline extents fail with either -EOPNOTSUPP or -EINVAL.
These cases were unsupported on btrfs because they used to lead to file
corruptions and were not trivial to implement.
But there's now a patchset that adds support for them, and the relevant
patch of that patchset has the following subject:
"Btrfs: implement full reflink support for inline extents"
So just remove these tests from test case btrfs/112, since this test
case is about testing only the unsupported reflink operations. A new
test case that verifies that these cases now work, as long as some other
new cases, will follow in another patch.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This allows us to run all those tests which simulate disk failures
using dmerror.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On some systems btrfs/179 fails because the check finds that there
is difference in the qgroup counts.
So as the intention of the test case is to test any hang like
situation during heavy snapshot create/delete operation with quota
enabled, so make sure the qgroup counts are consistent at the end of
the test case, so to make the check happy.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Try to punch hole with unaligned size and offset when the FS is full
and mounted with nodatacow option.
Mainly holes are punched at locations which are unaligned with the
file extent boundaries when the FS is full by data. As the punching
holes at unaligned location will involve truncating blocks instead
of just dropping the extents, it shall involve reserving data and
metadata space for delalloc and so data alloc fails as the FS is
full.
btrfs_punch_hole()
btrfs_truncate_block()
btrfs_check_data_free_space() <-- ENOSPC
We don't fail punch hole if the holes are aligned with the file
extent boundaries as it shall involve just dropping the related
extents, without truncating data extent blocks.
This test was orignally merged as btrfs/172 (commit 4c2c678cd), then
Iremoved by commit 538d8a4bcc. But it's decided to bring back this
test case, now the problem is better understood and the fix is
available in the ML as below.
Link: https://patchwork.kernel.org/patch/11357415/
Reviewed-by: Filipe Manana <fdmanana@suse.com>
(cherry picked from commit 4c2c678cd5)
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When btrfs/022 fails, its $seqres.full doesn't contain much useful info
to debug.
This patch will add extra debug, including subvolid and full "btrfs
qgroup show" output.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
Btrfs/022 sometimes fails with snapshot's reference mismatch with its
source.
[CAUSE]
Since commit fd08309295 ("fsstress: add the ability to create
snapshots") adds the ability for fsstress to create/delete snapshot and
subvolumes, fsstress will create new subvolumes under test dir.
For example, we could have the following subvolumes created by fsstress:
subvol a id=256
subvol b id=306
qgroupid rfer excl
-------- ---- ----
0/5 16384 16384
0/256 13914112 16384
...
0/263 3080192 2306048 << 2 *306* 048
...
0/306 13914112 16384 << 0/ *306
So when we're greping for subvolid 306, it matches qgroup 0/263 first,
which has difference size, and caused false alert.
[FIX]
Instead of greping "$subvolid" blindly, now grep "0/$subvolid" to catch
qgroupid correctly, without hitting rfer/excl values.
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a test to validate that we're not adjusting up i_size before
we have the appropriate file extents on disk. We had a problem
where i_size would be adjusted up without a contiguous range of file
extents, which isn't ok without a special option enabled.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation works correctly when a file has
shared extents with itself in the send snapshot, with a hole between them,
and the file size has increased in the send snapshot.
This currently fails in 5.5-rc kernels (regression) but is fixed by a
patch that has the following subject:
Btrfs: send, fix emission of invalid clone operations within the same file
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
As of the linux kernel commit fd0ddbe2509568 ("Btrfs: send, skip
backreference walking for extents with many references"), the test is no
longer dangerous and it's fast (takes 1 to 2 seconds on a modest vm with
a debug kernel). Therefore remove it from the dangerous group and add it
to the auto and quick groups as well.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test is merged under index 202 but the golden output contains
201. This makes the test always fail. Correct the number.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test removal of a subvolume via rmdir after it has been renamed into a
snapshot of the volume that originally contained the subvolume
reference.
This currently fails on btrfs but is fixed by the patch with the title
"btrfs: fix invalid removal of root ref"
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In my testing on 1GB zram devices btrfs/139 usually fails with
ENOSPC.
Add a requirement for 2GB scratch devices (empirically measured).
Signed-off-by: Johannes Thumshirn <jth@kernel.org>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
With btrfs-progs v5.4, btrfs/140 and btrfs/141 will fail.
[CAUSE]
Both tests are testing re-silvering of RAID1, thus they need to corrupt
on-disk data.
This requires to do manual logical -> physical bytes mapping in the test
case.
However the test case itself uses too many hard coded helper to grab
physical offset, which will change with mkfs.btrfs.
[FIX]
Use more flex helper, to get both devid and physical for such
corruption.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
When using btrfs-progs v5.4, btrfs/157 and btrfs/158 will fail:
btrfs/157 1s ... - output mismatch (see xfstests/results//btrfs/157.out.bad)
--- tests/btrfs/157.out 2018-09-16 21:30:48.505104287 +0100
+++ xfstests/results//btrfs/157.out.bad
2019-12-10 15:35:43.112390076 +0000
@@ -1,9 +1,9 @@
QA output created by 157
wrote 131072/131072 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
+wrote 65536/65536 bytes at offset 22020096
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
...
(Run 'diff -u xfstests/tests/btrfs/157.out xfstests/results//btrfs/157.out.bad' to see the entire diff)
btrfs/158 2s ... - output mismatch (see xfstests/results//btrfs/158.out.bad)
--- tests/btrfs/158.out 2018-09-16 21:30:48.505104287 +0100
+++ xfstests/results//btrfs/158.out.bad
2019-12-10 15:35:44.844388521 +0000
@@ -1,9 +1,9 @@
QA output created by 158
wrote 131072/131072 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
+wrote 65536/65536 bytes at offset 22020096
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
...
(Run 'diff -u xfstests/tests/btrfs/158.out xfstests/results//btrfs/158.out.bad' to see the entire diff)
[CAUSE]
This two tests use physical offset as golden output, while mkfs.btrfs
can do whatever it likes to arrange its chunk layout, thus physical
offset is never reliable.
And btrfs-progs commit c501c9e3b816 ("btrfs-progs: mkfs: match devid
order to the stripe index") just changed the layout.
So the output mismatch and failed.
[FIX]
In fact, that btrfs-progs commit not only changed offset, but also the
device sequence.
So we can't just simply remove the physical offset, but also need to use
proper helper to get both devid (as its device path) and physical offset
for corruption.
As long as mkfs.btrfs still uses sequential devid, these tests should
handle future chunk layout change without problem.
Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
When using btrfs-progs v5.4, btrfs/142 and btrfs/143 will fail:
btrfs/142 1s ... - output mismatch (see xfstests/results//btrfs/142.out.bad)
--- tests/btrfs/142.out 2018-09-16 21:30:48.505104287 +0100
+++ xfstests/results//btrfs/142.out.bad
2019-12-10 15:35:40.280392626 +0000
@@ -3,37 +3,37 @@
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
wrote 65536/65536 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
...
(Run 'diff -u xfstests/tests/btrfs/142.out xfstests/results//btrfs/142.out.bad' to see the entire diff)
[CAUSE]
Btrfs/14[23] test whether a read on corrupted stripe will re-silver
itself.
Such test by its nature will need to modify on-disk data, thus need to
get the btrfs logical -> physical mapping, which is done by near
hard-coded lookup function, which rely on certain stripe:devid sequence.
Recent btrfs-progs commit c501c9e3b816 ("btrfs-progs: mkfs: match devid
order to the stripe index") changes how we use devices in mkfs.btrfs,
this caused a change in chunk layout, and break the hard-coded
stripe:devid sequence.
[FIX]
This patch will do full devid and physical offset lookup, instead of old
physical offset only lookup.
The only assumption made is, mkfs.btrfs assigns devid sequentially for
its devices.
Which means, for "mkfs.btrfs $dev1 $dev2 $dev3", we get devid 1 for $dev1,
devid 2 for $dev2, and so on.
This change will allow btrfs/14[23] to handle even future chunk layout
change. (Although I hope this will never happen again).
This also addes extra debug output (although less than 10 lines) into
$seqres.full, just in case when layout changes and current lookup can't
handle it, developer can still pindown the problem easily.
Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In my testing on 1GB zram devices btrfs/187 usually fails with
ENOSPC.
Add a requirement for 8GB scratch devices (empirically measured).
Cc: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that when we have the no-holes feature enabled and a specific
metadata layout, if we punch a hole that starts at file offset 0 and
fsync the file, after replaying the log the hole exists.
This currently fails on btrfs but is fixed by a patch for the linux
kernel with the following subject:
"Btrfs: fix missing hole after hole punching and fsync when using NO_HOLES"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs/085 mount and works on $FLAKEY_DEV, but it's inspecting the
underlying $SCRATCH_DEV. Since writing to dm-flakey does not
invalidate page cache of $SCRATCH_DEV, the btrfs command can read a
stalled data from page cache. We should check the flakey device to
avoid such cache inconsistency.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify that both full and incremental send operations can issue
clone operations when a file has extents that are shared with itself
(at different offsets of course).
This currently fails on btrfs but is addressed by a patch for the
kernel titled:
"Btrfs: send, allow clone operations within the same file"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There are some testcases use below two kind of commands to get file
size, generalize the second way as global function _get_filesize()
to simply codes.
1. ls -l $1 | $AWK_PROG '{print $5}'
2. stat -c %s $1
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test case checks if btrfs can trim adjacent extents across
adjacent block groups boundary correctly.
The test case craft the following extents layout:
| BG1 | BG2 | BG3 |
Bytenr: X-8M X X+512M X+1G X+1G+128M
|//////|//////| | |//|
There is a long existing bug that, when btrfs is trying to trim the
range at [X+512M, X+1G+128M), it will only trim [X+512M, X+1G).
This test case is the regression test for this long existing bug.
It will verify the trimmed bytes by using loopback device backed up
by a file, and checking the bytes used by the file to determine how
many bytes are trimmed.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test if btrfs.ko sucessfully identifies and reports the missing
device, if the missed device contians no btrfs magic string.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test if btrfs.ko sucessfully identifies and reports the missing
device, if the missed device contians someother btrfs.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
I discovered a problem in btrfs where we'd end up pointing at a block we
hadn't written out yet. This is triggered by a race when two different
files on two different subvolumes fsync. This test exercises this path
with dm-log-writes, and then replays the log at every FUA to verify the
file system is still mountable and the log is replayable.
This test is to verify the fix
btrfs: fix incorrect updating of log root tree
actually fixed the problem.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana
Theodore Ts'o
Anand Jain
Qu Wenruo
Josef Bacik
Nikolay Borisov
Johannes Thumshirn
Johannes Thumshirn
Naohiro Aota
Chao Yu