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>
This is a long existing bug (from 2012) but exposed by a reporter
recently, that when compressed extent without data csum get written
to device-replace target device, the written data is in fact
uncompressed data other than the original compressed data.
And since btrfs still consider the data is compressed and will try
to read it as compressed, it can cause read error.
This is fixed by kernel commit ac0b4145d662 ("btrfs: scrub: Don't
use inode pages for device replace")
Reported-by: James Harvey <jamespharvey20@gmail.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if a power failure happens on a filesystem with quotas
(qgroups) enabled while the quota rescan kernel thread is running,
we will be able to mount the filesystem after the power failure.
This test is motivated by a recent regression introduced in the
linux kernel's 4.18 merge window and is fixed by a patch with the
title:
"Btrfs: fix mount failure when qgroup rescan is in progress"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since btrfs-dump-tree has been removed from btrfs-progs, use btrfs
inspect-internal dump-tree instead of btrfs-dump-tree.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add btrfs test that checks "rmdir" or "rm -r" command can delete a
subvolume like an ordinary directory.
This behavior has been restricted long time but becomes allowed by
kernel commit a79a464d5675 ("btrfs: Allow rmdir(2) to delete an
empty subvolume")
The test will be skipped if kernel does not support the feature,
which can be checked whether /sys/fs/btrfs/features/rmdir_subvol
exists or not.
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The btrfs/volume group represent a set of btrfs test-cases, which
shall intend to verify the relevant btrfs volume operations.
Under this new group all the existing btrfs/replace group would come
under, and also the device operations test cases which does not have
any group as of now. This group is helpful to verify the btrfs
volume related changes.
Run as
./check -g btrfs/volume
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Omar Sandoval
Filipe Manana
Qu Wenruo
Anand Jain
Misono Tomohiro
Lu Fengqi
Dave Chinner