Older kernels don't have /sys/fs/btrfs. btrfs/010 will happily run
until it goes to check its work against sysfs and finds those files
don't exist. This patch introduces a require check to ensure that
the sysfs files are present before running.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test creates a subshell that keeps running the 'cat' command
against a test file in an infinite loop, and after it kills the
subshell it unmounts the filesystem, after which point any 'cat'
subcommand that runs after or at that time will fail resulting in an
unexpected golden output:
$ ./check btrfs/081
btrfs/081 3s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/081.out.bad)
--- tests/btrfs/081.out 2018-09-16 21:30:48.501104179 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/081.out.bad 2019-01-24 20:36:18.989746185 +0000
@@ -206,5 +206,6 @@
Verifying file digests after cloning
14968c092c68e32fa35e776392d14523 SCRATCH_MNT/foo
14968c092c68e32fa35e776392d14523 SCRATCH_MNT/bar
+cat: /mnt/scratch/bar: No such file or directory
Verifying target file digest after umount + mount
14968c092c68e32fa35e776392d14523 SCRATCH_MNT/bar
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/081.out /home/fdmanana/git/hub/xfstests/results//btrfs/081.out.bad' to see the entire diff)
Ran: btrfs/081
Failures: btrfs/081
Failed 1 of 1 tests
Fix that by adding a proper trap to the reader loop function so that
the subshell waits for executed 'cat' commands when it receives
SIGTERM.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some variables inside the test's functions were used as local but
were not being declared as such. Add the local declaration for them.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup
accounting time out of commit trans") could cause ABBA deadlock
between backref lookup with write lock hold (subvolume deletion) and
other read/write operations.
It's going to be fixed by "btrfs: qgroup: Don't trigger backref walk
at delayed ref insert time".
This test will generate pwrite background workload, along with
constant subvolume creation and deletion to trigger the bug.
It needs some time to generate enough files to bump the tree height
to trigger the bug.
In my test environment, with 'unsafe' cache mode for the VM, it
triggers the bug at around 70~90 seconds. So I leave the default
runtime to 120s to make sure the bug will be triggered.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs/16[123] are all seed device related test cases, make them into
'seed' group.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With older util-linux(e.g. v2.17.2), running some tests(e.g.
generic/472, generic/495) got the following output:
-------------------------------------------------------
+mkswap: /mnt/xfstests/scratch/swap: warning: don't erase bootbits sectors
+ on whole disk. Use -f to force.
+mkswap: unable to relabel /mnt/xfstests/scratch/swap to system_u:object_r:swapfile_t:s0: Operation not supported
-------------------------------------------------------
1) Before commit c1f1b30 of util-linux, standard mkswap didn't zap bootbits
sectors and printed a warning until force option(i.e. -f) was given. We
define "mkswap -f" as MKSWAP_PROG and replace all standard mkswap with
$MKSWAP_PROG.
2) With mounting default SELinux context(e.g. system_u:object_r:root_t:s0),
standard mkswap tried to reset the type of default context to swapfile_t
if it is not swapfile_t, and then it failed and returned ENOTSUP expectedly
as we don't want to create any SELinux attr on purpose. standard mkswap
ignored this relabel error by commit d97dc0e of util-linux, but it still
reported the error before commit d97dc0e. We try to skip the reset step
in standard mkswap by mounting swapfile context directly.
Note:
We just mount swapfile context in related tests, and keep default context
in the rest of tests.
[Eryu: make mkswap a non-mandatory requirement and add comments on
"-f" option]
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test an incremental send operation in a scenario where the relationship
of ancestor-descendant between multiple directories is inversed, and
where multiple directories that were previously ancestors of another
directory now become descendents of multiple directories that used to be
their ancestors in the parent snapshot. This used to trigger an
infinite loop in the kernel code.
This is motivated by a bug found in btrfs which is fixed by the following
patch for the linux kernel:
"Btrfs: send, fix infinite loop due to directory rename dependencies"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make sure we don't shrink the device past an active swap file, but allow
shrinking otherwise, as well as growing and balance.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make sure that we don't remove or replace a device with an active swap
file but can add, remove, and replace other devices.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Swap files currently need to exist on exactly one device in exactly one
place.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Btrfs forbids some operations which should not be done on a swap file.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Swap files on Btrfs have some restrictions not applicable to other
filesystems.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We were sorting numerical values with the 'sort' tool without telling it
that we are sorting numbers, giving us unexpected ordering. So just pass
the '-n' option to the 'sort' tool.
Example:
$ echo -e "11\n9\n20" | sort
11
20
9
$ echo -e "11\n9\n20" | sort -n
9
11
20
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
A bug in file cloning/reflinking was recently found that afftected both
Btrfs and XFS, which was caused by allowing the cloning of an eof block
into the middle of a file when the eof is not aligned to the filesystem's
block size.
The fix consists of returning the errno -EINVAL to user space when the
arguments passed to the system call lead to the scenario of data
corruption. However this overlaps with some cases where the system call,
in Btrfs, returned -EOPNOTSUPP, which means we are trying to reflink
inline extents. That is unsupported in Btrfs due to the huge complexity
of supporting it (due to copying and trimming inline extents, deal with
eventual compression, etc).
We have a few btrfs test cases that verify that attempts to clone inline
extents result in a failure, and are currently expecting an -EINVAL error
message from the output of the cloner program. So create a filter that
converts error messages related to the -EOPNOTSUPP error to messages
related to the -EINVAL error, so that the test can run both on patched
and non-patched linux kernels.
The corresponding btrfs patch for the linux kernel is titled:
"Btrfs: fix data corruption due to cloning of eof block"
And the VFS change that introduces the -EINVAL error return was introduced
by the following linux kernel commit (landed in 4.20-rc1):
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
The btrfs patch is not yet in Linus' tree (it was submitted around the
same time as this change) and the VFS change was introduced in 4.10-rc1.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For any recent kernel, there is a chance that btrfs/057 reports false
errors.
The false error would look like:
btrfs/057 4s ... - output mismatch (see /home/adam/xfstests-dev/results//btrfs/057.out.bad)
--- tests/btrfs/057.out 2017-08-21 09:25:33.166666666 +0800
+++ /home/adam/xfstests-dev/results//btrfs/057.out.bad 2018-10-29 14:07:28.443651293 +0800
@@ -1,3 +1,3 @@
QA output created by 057
4096 4096
-4096 4096
+28672 28672
This is related to the fact that "btrfs subvolume sync" (or
vanilla sync) will not ensure orphan (unlinked but still exist) files to
be removed.
In fact, for that false error case, if inspecting the fs after umount,
its qgroup number is correct and btrfs check won't report qgroup error.
To fix the false alerts, just skip any manual qgroup number comparison,
and let fsck done after the test case to detect problem.
This also elimiate the necessary of using specified mount and mkfs
option, allowing us to improve coverage.
Reported-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some tests that use dmflakey to test filesystem consistency after a power
failure are in the 'log' group while others are not. So fix the
incosistency and put them all under the 'log' group.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test btrfs/108 does not test collapse, in fact btrfs does not even support
the fallocate collapse operation, so remove it.
Test btrfs/159 does not test collapse either, it tests hole punching, so
replace the collapse group with the punch group.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test was using the "mktemp -d" command to create a temporary
directory for storing send streams and computations from fssum,
without ever deleting them when it finishes. Therefore after running
it for many times it filled up all space from /tmp.
Fix this by using a temporary directory in TEST_DEV instead, as all
the more recent send/receive tests do, to store these files, and
making sure they get deleted when the test finishes. On average the
sum of the size of those files is between 5.5Mb to 6Mb, but changing
the number of operations for fsstress makes it even bigger.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Try to punch hole with unaligned size and offset when the FS is
full. 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.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Originally this test case was designed to work with 4K sectorsize.
Now enhance it to work with any sector sizes and makes the following
changes:
.out file not to contain any traces of sector size.
Use max_inline=0 mount option so that it meets the requisite of non inline
regular extent.
Don't log the md5sum results to the output file as the data size vary by
the sectorsize.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This bug is exposed by populating a high level qgroup, and then make
it childless with old qgroup numbers, and finally do rescan.
Normally rescan should zero out all qgroups' accounting number, but
due to a kernel bug which won't mark childless qgroups dirty, their
on-disk data is never updated, thus old numbers remain and cause
qgroup corruption.
Fixed by the following kernel patch:
"btrfs: qgroup: Dirty all qgroups before rescan"
[Eryu: removed useless _filter_xfs_io]
Reported-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we write into an unwritten extent of a file when there
is no more space left to allocate in the filesystem and then
snapshot the file's subvolume, after a clean shutdown the data was
not lost.
This test is motivated by a bug found by Robbie Ko for which there
is a fix whose patch title is:
"Btrfs: fix unexpected failure of nocow buffered writes after
snapshotting when low on space"
Reported-by: Robbie Ko <robbieko@synology.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since commit a79a464d5675 ("btrfs: Allow rmdir(2) to delete an empty
subvolume"), rm -r can delete a subvolume too.
This test assumes that rm -r does not delete a subvolume.
Currently the commit does not affect the test since qgroup items
still exist after subvolume deletion, but we plan to change the
behavior and remove them along with subvolume deletion.
So update the test and keep subvolume (and qgroup item) in any kernel
version.
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation produces correct results if
a file that has a prealloc (unwritten) extent beyond its EOF gets a
hole punched in a section of that prealloc extent.
This test is motivated by a bug found in btrfs which is fixed by a
patch for the linux kernel titled:
"Btrfs: send, fix incorrect file layout after hole punching beyond eof"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that we are able to do send operations when one of the source
snapshots (or subvolume) has a file that is deleted while there is
still a open file descriptor for that file.
This test is motivated by a bug found in btrfs which is fixed by a patch
for the linux kernel titled:
"Btrfs: fix send failure when root has deleted files still open"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Jeff Mahoney
Filipe Manana
Qu Wenruo
Xiao Yang
Omar Sandoval
Anand Jain
Misono Tomohiro