[BUG]
When btrfs/011 is executed on a fast enough system (fully memory backed
VM, with test device has unsafe cache mode), the test can fail like
this:
btrfs/011 43s ... [failed, exit status 1]- output mismatch (see /home/adam/xfstests-dev/results//btrfs/011.out.bad)
--- tests/btrfs/011.out 2019-07-22 14:13:44.643333326 +0800
+++ /home/adam/xfstests-dev/results//btrfs/011.out.bad 2019-09-18 14:49:28.308798022 +0800
@@ -1,3 +1,4 @@
QA output created by 011
*** test btrfs replace
-*** done
+failed: '/usr/bin/btrfs replace cancel /mnt/scratch'
+(see /home/adam/xfstests-dev/results//btrfs/011.full for details)
...
[CAUSE]
Looking into the full output, it shows:
...
Replace from /dev/mapper/test-scratch1 to /dev/mapper/test-scratch2
# /usr/bin/btrfs replace start -f /dev/mapper/test-scratch1 /dev/mapper/test-scratch2 /mnt/scratch
# /usr/bin/btrfs replace cancel /mnt/scratch
INFO: ioctl(DEV_REPLACE_CANCEL)"/mnt/scratch": not started
failed: '/usr/bin/btrfs replace cancel /mnt/scratch'
So this means the replace is already finished before we cancel it.
For fast system, it's very common.
[FIX]
In fill_scratch() after all the original file creations, do a timer
based direct IO write.
The extra write will take 2 * $wait_time, utilizing direct IO with 64K
block size, the write performance should be very comparable (although a
little faster) to replace performance.
So later cancel should be able to really cancel the dev-replace without
it finished too early.
Also, do extra check about the above write. If we hit ENOSPC we just
skip the test as the system is really too fast and the fs is not large
enough.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
xfs/030 always fails after d0e484ac69 ("check: wipe scratch devices
between tests") get merged.
Due to xfs/030 does a sized(100m) mkfs. Before we merge above commit,
mkfs.xfs detects an old primary superblock, it will write zeroes to
all superblocks before formatting the new filesystem. But this won't
be done if we wipe the first superblock(by merging above commit).
That means if we make a (smaller) sized xfs after wipefs, those *old*
superblocks which created by last time mkfs.xfs will be left on disk.
Then when we do xfs_repair, if xfs_repair can't find the first SB, it
will go to find those *old* SB at first. When it finds them,
everyting goes wrong.
So I try to wipe each XFS superblock if there's a XFS ondisk, then
try to erase superblock of each XFS AG by default mkfs.xfs geometry.
Thanks Darrick J. Wong helped to analyze this issue.
Reported-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Often this test can fail on unmount because a 'btrfs subvolume snapshot'
command is still running and using the scratch the mount point:
btrfs/036 168s ... umount: /home/fdmanana/btrfs-tests/scratch_1: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
(see /home/fdmanana/git/hub/xfstests/results//btrfs/036.full for details)
This happens because when we kill the process running the do_snapshots()
function we only kill the subshell and don't wait for any processes it
has spawned to finish before the subshell exits. Fix this by setting a
trap in the do_snapshots() function, so that when the subshell receives
a SIGTERM signal it waits for any running 'btrfs subvolume snapshot'
to finish before exitting. We were also not waiting for the subshell
to exit after sending it the SIGTERM signal, so fix that as well by
calling the 'wait' command after calling 'kill' to send that signal.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When running overlay tests using character devices as base fs partitions,
all overlay usecase results become 'notrun'. Function
'_overay_config_override' (common/config) detects that the current base
fs partition is not a block device and will set FSTYP to base fs. The
overlay usecase will check the current FSTYP, and if it is not 'overlay'
or 'generic', it will skip the execution.
For example, using UBIFS as base fs skips all overlay usecases:
FSTYP -- ubifs # FSTYP should be overridden as 'overlay'
MKFS_OPTIONS -- /dev/ubi0_1 # Character device
MOUNT_OPTIONS -- -t ubifs /dev/ubi0_1 /tmp/scratch
overlay/001 [not run] not suitable for this filesystem type: ubifs
overlay/002 [not run] not suitable for this filesystem type: ubifs
overlay/003 [not run] not suitable for this filesystem type: ubifs
When checking that the base fs partition is a block/character device,
FSTYP is overwritten as 'overlay'. This patch allows the base fs
partition to be a character device that can also execute overlay
usecases (such as ubifs).
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some testcases may require a special rename flag, such as
RENAME_WHITEOUT, so add support check for if a given rename flag is
supported in _require_renameat2.
[Eryu: rename the helper to _require_renameat2 while we're at it,
and add 'exchange' check to generic/398 and generic/419]
Signed-off-by: kaixuxia <kaixuxia@tencent.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Sometimes on fast enough test vm, btrfs/028 fails like:
btrfs/028 31s ... - output mismatch (see /home/adam/xfstests-dev/results//btrfs/028.out.bad)
--- tests/btrfs/028.out 2019-07-22 14:13:44.646666660 +0800
+++ /home/adam/xfstests-dev/results//btrfs/028.out.bad 2019-09-18 14:14:45.442131411 +0800
@@ -1,2 +1,3 @@
QA output created by 028
+/home/adam/xfstests-dev/tests/btrfs/028: line 64: kill: (2459) - No such process
Silence is golden
...
It's caused by killing already finished process.
There is no need for kill command to pollute the golden output, so
just redirect all of its stdout and stderr to null.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a test case where falloc is called on multiple holes with qgroup
enabled.
This can cause qgroup reserved data space leak and false EDQUOT
error even we're not reaching the limit.
The fix is titled:
"btrfs: qgroup: Fix the wrong target io_tree when freeing
reserved data space"
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
xfstests should decide if xfs_quota needs the -f option by
_require_xfs_quota_foreign, not write the -f option after
$XFS_QUOTA_PROG manually. The later way will cause unexpected error
on an old system which xfsprogs doesn't support the -f option.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Tested-by: Murphy Zhou <jencce.kernel@gmail.com>
Acked-by: Murphy Zhou <jencce.kernel@gmail.com>
Acked-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/564 wants to test for copy_range -f, but as it's implemented
it calls copy_range with a length of zero which will silently return
success from the VFS (at least on some kernels) even if the underlying
fs doesn't support it.
So patch this up 2 ways; perform the test with an explicit length
so it's not a no-op, and go ahead test copy_range w/o -f in the test
first just to be on the safe side (and for clearer failure messages.)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We have generic dm-logwrites with fsstress test case (generic/482),
but it doesn't cover fs specific operations like btrfs snapshot
creation and deletion.
Furthermore, that test is not heavy enough to bump btrfs tree height
by its short runtime.
And finally, btrfs check doesn't consider dirty log as an error,
unlike ext*/xfs, that's to say we don't need to mount the fs to
replay the log, but just running btrfs check on the fs is enough.
So introduce a similar test case but for btrfs only.
The test case will stress btrfs by:
- Use small nodesize to bump tree height
- Create a base tree which is already high enough
- Trim tree blocks to find possible trim bugs
- Call snapshot creation and deletion along with fsstress
Also it includes certain workaround for btrfs:
- Allow _log_writes_mkfs to accept extra mkfs options
- Use no-holes feature
To avoid missing hole file extents.
Although that behavior doesn't follow the on-disk format spec, it
doesn't cause data loss. And will follow the new on-disk format spec
of no-holes feature, so it's better to workaround it.
And an optimization for btrfs only:
- Use replay-log --fsck/--check command
Since dm-log-writes records bios sequentially, there is no way to
locate certain entry unless we iterate all entries.
This is becoming a big performance penalty if we replay certain a
range, check the fs, then re-execute replay-log to replay another
range.
We need to records the previous entry location, or we need to
re-iterate all previous entries.
Thankfully, replay-log has already address it by providing --fsck and
--check command, thus we don't need to break replay-log command.
Please note, for fast storage (e.g. fast NVME or unsafe cache mode),
it's recommended to use log devices larger than 15G, or we can't
record the full log of just 30s fsstress run.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test fails sporadically when trying to unmount the scratch filesystem
because a filefrag process is still running against a file that exists on
the scrach filesystem. This is because killing the subshell running the
fiemap_work() function does not wait for any filefrag process to complete
first. We need to set a trap for the SIGTERM signal on the subshell so
that it waits for any filefrag process before exitting.
The failure resulted in error messages like the following:
btrfs/079 57s ... umount: /home/fdmanana/btrfs-tests/scratch_1: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
(see /home/fdmanana/git/hub/xfstests/results//btrfs/079.full for details)
Fix this by adding a trap for SIGTERM.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On file systems with a block size smaller than the page size, hole
punching can leave the pages at the beginning and the end of the
hole partially mapped to disk blocks. Make sure writes to those
pages are handled correctly.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In order to check that the filesystem generation does not change
after failure to set a property, the test expects a specific
generation number of 7 in its golden output. That currently works
except when using the v2 space cache mount option (MOUNT_OPTIONS="-o
space_cache=v2"), since the filesystem generation is 8 because
creating a v2 space cache adds an additional transaction commit. So
update the test to not hardcode specific generation numbers in its
golden output and just output an unexpected message if the
generation number changes.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This flag is never set. Furthermore, there does not seem to be any need
to set O_DIRECT for lock testing.
Remove the D_flag
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Reviewed:-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Those 2 tests fail on btrfs on a ppc64 system with 64k pages. This is
caused by the improved minimum device size calculation in upstream
btrfs-progs (commit: 31d228a2eb98 ("btrfs-progs: mkfs: Enhance minimal
device size calculation to fix mkfs failure on small file")).i
Xfstests implicitly uses '--mixed' options for filesystems smaller than
256mb thus the minimum filesystem size require is derived from the
following equation: 2 * (4mb + nodesize << 10). On a 64k page system
this evaluates to 2 * (4m + 64m) = 136m. This resuts in failures such:
mkfs.btrfs -b $((100 * 1048576)) btrfs-test.img
ERROR: size 104857600 is too small to make a usable filesystem
ERROR: minimum size for btrfs filesystem is 114294784
when running _scratch_mkfs_sized $((100 * 1048576)).
Fix this by increasing the minimum filesystem size to 196 megabytes
which makes mkfs.btrfs happy again and allows the test to proceed.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The _casefold_lsattr_dir function lists all of the file attributes.
As result, tests/generic/556.out has an ext4-specific assumption
that the test directories will have the Extents attribute. That
won't be true for all file systems, and it won't even be true for
ext4 file systems that do not have the extents feature enabled.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test that checks for xfs drivers that fail to
unlock the inode after changing the group id fails with EDQUOT. It
pairs with "xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails
due to EDQUOT".
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
FIBMAP only returns a negative value when the underlying filesystem
does not support FIBMAP or on permission error. For the remaining
errors, i.e. those usually returned from the filesystem itself, zero
will be returned.
We can not trust a zero return from the FIBMAP, and such behavior
made generic/223 succeed when it should not.
Also, we can't use perror() only to print errors when FIBMAP failed,
or it will simply print 'success' when a zero is returned.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Btrfs does COW, so when we unlink the file we need to update
metadata and write it to a new location, which we can't do because
the thinp is full. This results in an EIO during a metadata write,
which makes us flip read only, thus making it impossible to fstrim
the fs. Just make it so we skip this test for btrfs.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add the missing range arguments to the sync_range command in this test:
according to Josef Bacik, the sync_range command is required to make the test
reproduce the critical situation reliably.
[Eryu: fix dumping xfs_io output to $seqres.full, don't check
xfs_io's exit status]
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Suggested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since the iomap code are moving to fs/iomap/ we have to add new
entries to the aiodio dmesg filter to reflect this. It's still
possible for filesystems using iomap for directio to cough up
WARNings when a direct write collides with a buffered write, since
in some cases we catch that early enough to have the direct write
return EIO (which was covered by filter $warn7 previously).
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
While the kill statement added in the previous patch usually
suffices to shut down the bash loop that runs the duperemove
processes, for whatever reason this sometimes fails to kill
duperemove. Kill the duperemove processes directly after removing
the run file, which should cause the bash loop to exit immediately.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Qu Wenruo
Zorro Lang
Filipe Manana
Zhihao Cheng
Yang Xu
kaixuxia
Eric Sandeen
Andreas Gruenbacher
Ira Weiny
Nikolay Borisov
Theodore Ts'o
Darrick J. Wong
Carlos Maiolino
Josef Bacik