Currently _link_output_file() selects output file suffix based on the
current operating system. Make it more versatile by allowing selection
of output file suffix based on any feature string. The idea is that
in config file ($seq.cfg) there are several lines like:
feat1,feat2: suffix
The function is passed a feature string (or uses os_name,MOUNT_OPTIONS
if no argument is passed) and selects output file with a suffix for
which all features are present in the feature string. If there is no
matching line, output with 'default' suffix is selected.
Update all tests using _link_out_file to the new calling convention.
Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
generic/081 and 108 fails in RHEL 6.3, like:
# ./check generic/081
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 kerneldev 4.2.0-rc5_HEAD_d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754_+
MKFS_OPTIONS -- /dev/vdd
MOUNT_OPTIONS -- /dev/vdd /var/ltf/tester/scratch_mnt
generic/081
[failed, exit status 1] - output mismatch (see /var/lib/xfstests/results//generic/081.out.bad)
--- tests/generic/081.out 2015-07-13 17:07:03.000000000 +0800
+++ /var/lib/xfstests/results//generic/081.out.bad 2015-10-28 12:20:49.000000000 +0800
@@ -1,2 +1,3 @@
QA output created by 081
Silence is golden
+ERROR: checking status of /dev/mapper/vg_081-base_081: No such file or directory
Ran: generic/081
Failures: generic/081
Failed 1 of 1 tests
Reason:
Command of "lvm lvcreate --yes" failed because lvm in RHEL 6.3
don't support '--yes' option.
Fix:
Use yes pipe instead '--yes' option for lvm, to make the command
support both new and old version of lvm.
Suggested-by: Dave Chinner <david@fromorbit.com>
Suggested-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Teach _check_dmesg to look for improper RCU usage and circular locking
dependency messages. It's useful to check for these as they might point
to a real problem in the filesystem's implementation (or the current
implementation just confuses the checker, probably worth simplifying
the filesystem's implementation).
Currently the test btrfs/071 for example triggers such warnings:
[ 912.924839] ===============================
[ 912.925617] [ INFO: suspicious RCU usage. ]
[ 912.926394] 4.3.0-rc5-btrfs-next-17+ #1 Not tainted
[ 912.927274] -------------------------------
[ 912.928364] fs/btrfs/volumes.c:1977 suspicious rcu_dereference_check() usage!
[ 912.929626]
[ 912.929626] other info that might help us debug this:
[ 912.929626]
[ 912.931197]
[ 912.931197] rcu_scheduler_active = 1, debug_locks = 1
[ 912.933822] 4 locks held by btrfs/6400:
[ 912.934558] #0: (&fs_info->dev_replace.lock_finishing_cancel_unmount){+.+...}, at: [<ffffffffa046a193>] btrfs_dev_replace_finishing+0x3e/0x696 [btrfs]
[ 912.948929] #1: (uuid_mutex){+.+.+.}, at: [<ffffffffa046a24a>] btrfs_dev_replace_finishing+0xf5/0x696 [btrfs]
[ 912.950987] #2: (&fs_devs->device_list_mutex){+.+.+.}, at: [<ffffffffa046a263>] btrfs_dev_replace_finishing+0x10e/0x696 [btrfs]
[ 912.953265] #3: (&fs_info->chunk_mutex){+.+...}, at: [<ffffffffa046a278>] btrfs_dev_replace_finishing+0x123/0x696 [btrfs]
(...)
[ 912.987973] ======================================================
[ 912.989242] [ INFO: possible circular locking dependency detected ]
[ 912.990583] 4.3.0-rc5-btrfs-next-17+ #1 Not tainted
[ 912.990801] -------------------------------------------------------
[ 912.990801] btrfs/6400 is trying to acquire lock:
[ 912.990801] (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff8119d202>] __blkdev_get+0xa3/0x3d9
[ 912.990801]
[ 912.990801] but task is already holding lock:
[ 912.990801] (&fs_info->chunk_mutex){+.+.+.}, at: [<ffffffffa046a278>] btrfs_dev_replace_finishing+0x123/0x696 [btrfs]
[ 912.990801]
[ 912.990801] which lock already depends on the new lock.
[ 912.990801]
[ 912.990801]
[ 912.990801] the existing dependency chain (in reverse order) is:
(...)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Commit 20d7bfad2d ("reflink: add test support routines to a separate
file") moved the function _require_cp_reflink to the new file
common/reflink but forgot to make btrfs/091 source that file, leading
to the following failure:
$ ./check btrfs/091
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian3 4.3.0-rc5-btrfs-next-17+
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/091 1s ... - output mismatch (see .../results//btrfs/091.out.bad)
--- tests/btrfs/091.out 2015-05-03 01:19:42.128976975 +0100
+++ .../results/btrfs/091.out.bad 2015-11-18 15:56:35.332745132 +0000
@@ -1,4 +1,5 @@
QA output created by 091
+./tests/btrfs/091: line 49: _require_cp_reflink: command not found
wrote 262144/262144 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
65536 65536
...
(Run 'diff -u tests/btrfs/091.out .../results/btrfs/091.out.bad' \
to see the entire diff)
So just make btrfs/091 source common/reflink in order to know the
definition of _require_cp_reflink.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that doing a direct IO write against a file range that contains one
prealloc extent and one compressed extent works correctly.
From the linux kernel 4.0 onwards, this either triggered an assertion
failure (leading to a BUG_ON) when CONFIG_BTRFS_ASSERT=y or resulted
in an arithmetic underflow of an inode's space reservation for write
operations.
That issue is fixed by the following linux kernel patch:
"Btrfs: fix extent accounting for partial direct IO writes"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When running the test generic/269 against a fast scratch device (loopback
device backed by a file on tmpfs) I often got a test failure due to the
fact that the fsstress job had already completed before the test attempted
to kill it, producing the following failure output:
generic/269 91s ... - output mismatch (see .../generic/269.out.bad)
--- tests/generic/269.out 2014-11-17 20:59:50.974203000 +0000
+++ /home/fdmanana/git/hub/xfstests/results//generic/269.out.bad 2015-11-13 15:41:59.669893035 +0000
@@ -3,3 +3,4 @@
Run fsstress
Run dd writers in parallel
+./tests/generic/269: line 59: kill: (13417) - No such process
...
(Run 'diff -u tests/generic/269.out .../generic/269.out.bad' to see the entire diff)
So fix this false failure by redirecting the standard output and error
from the kill into the seq file.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This issue was found by testing f2fs module with generic/285, and the
related bug has already been fixed since commit 2e023174a88d ("f2fs:
avoid data offset overflow when lseeking huge file"), but forgot to fix
it in xfstest suit.
The wrong result printed is printed in log below:
10. Test a huge file for offset overflow
10.01 SEEK_HOLE expected 65536 or 0, got 65536. succ
10.02 SEEK_HOLE expected 65536 or 0, got 65536. succ
10.03 SEEK_DATA expected 0 or 0, got 0. succ
10.04 SEEK_DATA expected 1 or 1, got 1. succ
10.05 SEEK_HOLE expected 0 or 0, got 0. FAIL
10.06 SEEK_DATA expected -65536 or -65536, got -65536. succ
10.07 SEEK_DATA expected -65535 or -65535, got -65535. succ
10.08 SEEK_DATA expected -65536 or -65536, got -65536. FAIL
The result printed in the log shows that when some test cases failed, the
data we expected and got are the same that is not correct obviously.
The reason is that we cast the result from type off_t(64-bit) to type
long(32-bit) when doing huge file offset seeking tests in 32-bit machine.
This patch fixes the wrong printing issue.
Signed-off-by: Chao Yu <chao2.yu@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case tests if we are able to disable quotas on a filesystem
while a quota rescan is running. Up to now (4.3) this would result
in a kernel NULL pointer dereference.
Fixed by patch (btrfs: qgroup: fix quota disable during rescan).
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case tests if we are able to unmount a filesystem while
a quota rescan is running. Up to now (4.3) this would result
in a kernel NULL pointer dereference.
Fixed by patch (btrfs: qgroup: exit the rescan worker during umount).
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
After patch "ext4: Fix races of writeback with punch hole and zero
range" we don't flush range that's going to be zeroed out which results
in different final extent layout because some extents will be zeroed-out
instead of being split. Update the output file accordingly.
Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Older versions of awk do not accept interval regexps by default. Avoid
them in _filter_fiemap to keep better compatibility since it's pretty
trivial.
Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
To avoid having many tests repeating the following pattern:
_load_flakey_table $FLAKEY_DROP_WRITES
_unmount_flakey
_load_flakey_table $FLAKEY_ALLOW_WRITES
_mount_flakey
add the helper function _flakey_drop_and_remount to remove
the existing duplicated code and serve as a shortcut.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that a file fsync works after punching a hole for the same file
range multiple times, and that after log/journal replay the file's
content and layout are correct.
This test is motivated by a bug found in btrfs, which is fixed by
the following linux kernel patch:
"Btrfs: fix hole punching when using the no-holes feature"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add a few horrible opt-in stress tests to see what happens if we try
to reflink the same block billions of times, and what happens if we
run out of space while reflinking a file.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Ensure that copy-on-writing a reflinked file when there's no free disk
space reflects the desired ENOSPC back to userspace during the write
call. Tests the buffered IO, direct IO, and mmap write paths.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Make sure that running reflink ops while other IO is ongoing doesn't
break the filesystem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check that the various XFS tools still work properly on reflinked XFSes.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check that we can feed bad inputs to reflink/dedupe and it'll reject
them.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check that the free block counts seem to be handled correctly in
the reflink operation and subsequent attempts to rewrite reflinked
copies.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check that the variants of fallocate (allocate, punch, zero range,
collapse range, insert range) do the right thing when they're run
against a range of reflinked blocks.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Ensure that CoW happens correctly with buffered, directio, and mmap writes.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test the operation of the btrfs (and now xfs) reflink and dedupe
ioctls at various file offsets and with matching and nonmatching
files.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Put all the reflink/dedupe-related test support routines in a separate
file, then modify the existing reflink tests to use them.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Move the cp --reflink tests from btrfs/ to generic/ since xfs now
supports that ioctl.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Jan Kara
Jan Kara
Zhao Lei
Filipe Manana
Chao Yu
Justin Maggard
Darrick J. Wong