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>
It's just a one line wrapper that adds complexity, remove it. Move
the couple of calls in tests to common/config, but leave the xfsdump
setup in place and just convert it.
[Eryu: add the missing CHECKBASHISMS_PROG definition, define
mkfs.btrfs and mkfs.f2fs with set_mkfs_prog_path_with_opts]
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Update the group files to annotate those tests which have a
_require_xfs_io_command for punch, collapse, insert, and zero. This
makes it easier to exclude tests that use one of these fallocate
commands. Or if you want to specifically test for those fallocate
commands you can do this.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This adds a regression test for the following kernel patch:
b4678df184b3 ("errseq: Always report a writeback error once")
This is motivated by some rather odd behavior done by the PostgreSQL
project. The main database writers will offload the fsync calls to a
separate process, which can open files after a writeback error has
already occurred.
This used to work with older kernels that reported the error to only
one fd, but with the errseq_t changes we lost the ability to see
errors that occurred before the open. The above patch restores that
behavior.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The 3 tests that _require_xfs_io_command "flink", actually require
O_TMPFILE support and flink command, but the former is far unlikely
to be missing. The test btrfs/058 doesn't even use the flink
command.
When running these tests on a filesystem that does not support
O_TMPFILE (e.g. overlayfs) the result is not very infomative:
generic/004 1s ... [not run] xfs_io flink failed (old kernel/wrong fs?)
Decouple the requirements for "flink" command and "-T" command line
flag and require the former explicitly in tests that use it.
As a result the report is now more informative:
generic/004 1s ... [not run] O_TMPFILE is not supported
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Use common helper functions where needed. By doing this it improves
code readability and debugging of it.
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 test case takes a long time to complete at the default
LOAD_FACTOR=1, so reduce the nr_extents to 256, so for larger
systems it can still use higher LOAD_FACTOR.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs-progs patch[1] replaced read(2) write(2) with splice(2) and
caused the append-redirect to stop working.
Before:
btrfs send /btrfs/ro_send > /dev/null
At subvol /btrfs/ro_snap
btrfs send /btrfs/ro_send >> /dev/null
At subvol /btrfs/ro_snap
After:
btrfs send /btrfs/ro_send > /dev/null
At subvol /btrfs/ro_snap
btrfs send /btrfs/ro_send >> /dev/null
At subvol /btrfs/ro_snap
ERROR: failed to read stream from kernel: Invalid argument
Further in the test case the line..
btrfs/130
::
_run_btrfs_util_prog send $SCRATCH_MNT/ro_snap > /dev/null 2>&1
which intended to redirect send output to /dev/null, but ended up
append redirect to the $seqres.full file. And so this test case
failed as 'Invalid argument' for sometime now.
Still as append of a btrfs send output doesn't make sense, so fix
the fstests.
Also adds logs going into $seqres.full.
[1]
ba23855cdc8961bbaef1fcad4854d494cdb3afd3
btrfs-progs: send: use splice syscall instead of read/write to transfer buffer
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 that when we have the no-holes mode enabled and a specific
metadata layout, if we punch a hole and fsync the file, at replay
time the whole hole was preserved.
This issue is fixed by the following btrfs patch for the linux
kernel:
"Btrfs: fix fsync after hole punching when using no-holes feature"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In the case of compression, each 128K input data chunk will be
compressed to 4K (because of the characters written are duplicate).
Therefore we have to write (128K * 16) to make sure every stripe can be
hit.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Because of commit e76e13ce8c ("fsstress: implement the
clonerange/deduperange ioctls"), dedupe makes the number of references
to the same extent item increase so much that the default 4K buffer of
logical-resolve is no longer sufficient.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Previously _scratch_mount didn't check the mount status and most
tests continue to run even if the mount failed (unless test checks
for the mount status explicitly). This would result in running tests
on the underlying filesystem (usually rootfs) and implicit test
failures, and such failures can be annoying and are usually hard to
debug.
Now _fail test by default if _scratch_mount failed and introduce
_try_scratch_mount for tests that need to check mount results
themselves.
Suggested-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
btrfs/150 uses RAID1 profile and make SCRATCH_DEV fail for test.
However, if SCRATCH_DEV_POOL consists more than two devices,
SCRATCH_DEV may not be used for RAID1 pair and the tests may not run
as expected.
Fix this by add _scratch_dev_pool_get/put like other tests (141, 143
etc.) do.
Signed-off-by: Tomohiro Misono <misono.tomohiro@jp.fujitsu.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test, btrfs/027, runs tests against different raid profiles in
a loop, if one of them aborts, it also fails the following ones with
errors like,
Test -m raid10 -d raid10
ERROR: /dev/xxx is mounted
Test -m raid5 -d raid5
ERROR: /dev/xxx is mounted
Test -m raid6 -d raid6
ERROR: /dev/xxx is mounted
_scratch_unmount is added to avoid the above.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
btrfs/011 replaces the first device in SCRATCH_DEV_POOL in test,
which is SCRATCH_DEV, and it fails to umount SCRATCH_MNT when it
aborts, because _cleanup doesn't do any umount. This may leave
SCRATCH_DEV not used but other devices from SCRATCH_DEV_POOL still
mounted on SCRATCH_MNT. Then this results in SCRATCH_DEV unusable
for subsequent tests because _require_scratch couldn't umount detect
& umount SCRATCH_DEV correctly.
Fix it by umounting SCRATCH_MNT in _cleanup, so the test always
umounts the devices on exit.
[eguan: add comments and rewrite summary and commit log]
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Tested-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Some test cases (AFAIK, btrfs RAID recovery test cases) read out
certain location to verify its data.
Such read is mostly OK, but the golden output contains the on-disk
offset, which can differ due to underlying chunk change. (This time
is mkfs chunk layout change for btrfs)
So introduce macro _filter_xfs_io_offset to filter out the offset part
wrote 65536/65536 bytes at offset 136708096
^^^^^^^^^^^^^^^^^^^^
And offset from "pread -v"
08260000: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
^^^^^^^^^
Only btrfs/14[0-3] are affected.
Reported-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is to reproduce a bug of scrub, with which scrub is unable to
repair raid6 corruption as expected.
The kernel side fixes are
Btrfs: make raid6 rebuild retry more
Btrfs: fix scrub to repair raid6 corruption
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Filipe Manana
Lu Fengqi
Misono Tomohiro
Dave Chinner
Anand Jain
Dave Chinner
Theodore Ts'o
Jeff Layton
Amir Goldstein
Eryu Guan
Liu Bo
Qu Wenruo