xfs: test xfsprogs log formatting infrastructure

The xfsprogs libxfs layer implements its own log formatting code to
support utilities that might need to format the log, such as mkfs,
repair, metadump, etc. This code is fairly independent from kernel log
writing code. Therefore, add a test that reformats the log from
userspace with various supported log stripe unit alignments and verifies
that the end result is a correctly formatted log.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: mkfs.btrfs now requires --mixed for small filesystems

generic/077 fails on btrfs progs v4.3:
 # ./check generic/077
 FSTYP         -- btrfs
 PLATFORM      -- Linux/x86_64 lenovo 4.4.0-rc2_HEAD_1ec218373b8ebda821aec00bb156a9c94fad9cd4_
 MKFS_OPTIONS  -- /dev/sdb6
 MOUNT_OPTIONS -- /dev/sdb6 /var/ltf/tester/scratch_mnt

 generic/077 344s ... [failed, exit status 1] - output mismatch (see /var/lib/xfstests/results//generic/077.out.bad)
     --- tests/generic/077.out   2015-11-23 17:06:27.144983112 +0800
     +++ /var/lib/xfstests/results//generic/077.out.bad  2015-11-23 17:41:25.187062895 +0800
     @@ -1,7 +1,5 @@
      QA output created by 077
      *** create filesystem
     -*** set default ACL
     -*** populate filesystem, pass #1
     -*** populate filesystem, pass #2
     -*** all done
     +mkfs failed
     +(see /var/lib/xfstests/results//generic/077.full for details)
      *** unmount
 Ran: generic/077
 Failures: generic/077
 Failed 1 of 1 tests

Reason:
 btrfs progs v4.3 use non-mixed blockgroup for small volume as default,
 it need at least 100M to build a filesystem.

Fix:
 Force mixed mode for small-size fs, to make mkfs success.

Suggested-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4/001: Select different output based on mount options

Depending on mount options, we handle unwritten extents somewhat
differently. So sometimes we end up zeroing out unwritten extent and
converting it to written one and sometimes we just split it. Choose
expected output based on mount options.

Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: Improve _link_output_file to be more versatile

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>

common: Factor out function to get OS name

Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/081: Support old version of lvm

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>

common: Add more checks to _check_dmesg

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>

btrfs/091: fix missing common/reflink include

Commit 20d7bfad2d38 ("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>

btrfs: test direct IO write against compressed extent

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>

generic/269: Fix failure due to race killing fsstress job

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>

generic/285: fix the wrong result printed in full log

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>

btrfs: test quota disable during quota rescan

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>

btrfs: test unmount during quota rescan

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>

ext4/001: Update output

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>

_filter_fiemap: Avoid awk interval regexps

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>

common: add helper function _flakey_drop_and_remount

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>

fstests: generic test for fsync after hole punching

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>

reflink: test what happens when we hit resource limits

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>

reflink: test that CoW writes fail when we're out of space

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>

reflink: concurrent operations tests

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>

xfs: test xfs-specific reflink pieces

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>

reflink: test error conditions due to bad inputs

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>

reflink: test accuracy of free block counts

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>

reflink: test the various fallocate modes

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>

reflink: test CoW behaviors of reflinked files

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>

reflink: basic tests of the reflink and dedupe ioctls

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>

reflink: add test support routines to a separate file

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>

btrfs: move btrfs reflink tests to generic

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>

generic/312: fix dev_blocks calculation

Current calculation fails when there are many same type of devices
with the testing device, eg sda1 sda2 ... sda10, sda11, sda12 ..
$(grep sda1 /proc/partitions) gets multiple numbers.

$ grep ram1 /proc/partitions
   1        1   10485760 ram1
   1       10   10485760 ram10
   1       11   10485760 ram11
   1       12   10485760 ram12
   1       13   10485760 ram13
   1       14   10485760 ram14
   1       15   10485760 ram15
$ grep -w ram1 /proc/partitions
   1        1   10485760 ram1

Fix this by adding the -w option to grep to match the block device
exactly.

Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs/012: add a regression test for deleting ext2_saved

Btrfs now has changed to delete subvolume/snapshot asynchronously,
which means that after umount, if we've already deleted 'ext2_saved',
rollback can still be completed, which should not.

So this adds a regression test for this.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4: move 30[1234] from the dangerous to the auto group

The ext4/301, ext4/302, ext4/303, and ext4/304 tests are not crashing
on 3.10.89, 3.14.53, 3.18.21, 4.1.8, and 4.3-rc2.  So promote these
tests from the dangerous to the auto group.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: cloning of compressed inline extent after truncation

Test that truncating a file that consists of a compressed and inlined extent
to a smaller size and then cloning it into another file is not possible and
does not result in leaking stale data (data past the truncation offset) nor
losing data in the clone operation's destination file.

This btrfs issue is fixed by the linux kernel patch titled:

  "Btrfs: fix truncation of compressed and inlined extents"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: properly quote strings tested with -n

Per the Advanced Bash Scripting Guide:

"The -n test requires that the string be quoted within the test brackets.
Using an unquoted string with ! -z, or even just the unquoted string
alone within test bracket normally works, however, this is an unsafe
practice. Always quote a tested string."

And indeed:

$ unset FOOBAR
$ [ -n $FOOBAR ] || echo nope
$ [ -n "$FOOBAR" ] || echo nope
nope

Ran into this on a box w/o the attr program installed, and passed
_require_attrs.  Quoting the string fixes this; fix it there
and other occurrences in common/* as well.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs/112: add missing _require_xfs_io_command for falloc

I forgot to add the requirement for the xfs_io command "falloc", which
the test makes use of. Also fixed a weird indentation (mix of spaces
and tabs) for one line of a comment.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs/035: check for data loss

The test currently verifies that cloning one file with an inline extent
with a size of 10 bytes into a file with an inline extent that has a size
of 20 bytes succeeds. But this results in data loss, because the btrfs
clone operation drops the 20 bytes inline extent from the destination
inode and then copies the 10 bytes inline extent from the source file
into the destination file, resulting in data loss of the last 10 bytes
of data that the destination file had.

Fixing btrfs to correctly operate for this case (not resulting in data
loss) is actually a lot of work and brings a lot of complexity, specially
considering that any of the inline extents can be compressed. For the
moment there's a fix to make the clone operation return the errno
EOPNOTSUPP and not touch any of the inodes. This is the same approach
we do for other cases involving operation against inline extents, so
this just adds one more case that should have never been allowed.
Cloning inline extents is a rare operation and pointless, since it
involves copying them and not doing any actual deduplication or saving
space.

The btrfs patch for the linux kernel that prevents this data loss,
and fixes some file corruption cases, is titled:

  "Btrfs: fix file corruption and data loss after cloning inline extents"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test for cloning of inline extents

Test several cases of cloning inline extents that used to lead to file
corruption or data loss.

These file corruption and data loss cases are fixed by the linux kernel
patch titled:

  "Btrfs: fix file corruption and data loss after cloning inline extents"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

src/runas: Fixes and cleanups

The runas helper runs a command as another user and/or with different group
memberships.  Fix the following problems:

 * Use setgid instead of setegid and setuid instead of seteuid.
   Otherwise, the command will run with the original real UID
   and/or GID; those could be made the effective IDs again.

 * When only a GID is specified, remove all supplementary
   GIDs.  Otherwise, the command would remain in the same
   supplementary groups as runas -- which often is the root
   group.

 * Use execvp instead of execv which searches the PATH when
   necessary.  The runas helper is always called either with a
   '/' in the pathname or as "runas ... `which program`", so
   we obviously want PATH lookup, anyway.

 * There is no advantage in fork'ing and waiting for the child
   over directly exec'ing the command; the test cases already
   have to deal with commands which can be killed by signals.

Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test sending snapshots received from other filesystems

Test that sending a snapshot received from a different filesystem is
possible for both full and incremental send operations.

This used to work until the linux kernel release 4.2, but a commit [1] in
that release introduced a regression which did not allow this anymore.

The regression is fixed by the linux kernel patch titled:

  "btrfs: fix resending received snapshot with parent"

[1] 37b8d27de5d0 ("Btrfs: use received_uuid of parent during send")

Cc: Josef Bacik <jbacik@fb.com>
Cc: Robin Ruede <rruede+git@gmail.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: send/receive across different filesystems

Test that sending and receiving snapshots across different filesystems
works for full and incremental send operations.

This used to fail before the linux kernel release 4.2. The linux kernel
commit that fixed this issue was the following:

  37b8d27de5d0 ("Btrfs: use received_uuid of parent during send")

Cc: Josef Bacik <jbacik@fb.com>
Cc: Robin Ruede <rruede+git@gmail.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/167: wait for fsstress to exit

sync doesn't guarantee all fsstress processes died, and sometimes it
ends up running fsck on a mounted fs.

Use wait to wait for fsstress to exit.

Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: send with shared and compressed extents

Test that a send operation works correctly with reflinked files (cloned
extents which multiple files point to) that have compressed extents.

This used to fail on btrfs, resulting in different file digests after
receiving the send stream, and got fixed by the linux kernel patch
titled:

  "Btrfs: send, fix file corruption due to incorrect cloning operations"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fstests: test btrfs send for reflinked files

Test that a send operation works correctly with reflinked files (cloned
extents which multiple files point to).

The btrfs issue was fixed by the linux kernel patch titled:
"Btrfs: send, fix file corruption due to incorrect cloning operations"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fstests: btrfs: Check if fallocate re-truncates page beyond EOF

Even the fallocate range doesn't cover the last page of a file, btrfs
will still re-truncate the last page.

Such behavior is completely duplicated and unneeded, and fixed by the
following kernel patch:

btrfs: Avoid truncate tailing page if fallocate range doesn't exceed
inode size

Add this test case to check that malfunction.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: test extending sub-block AIO writes for races

This tests Brian Foster's fix for xfs:

   xfs: always drain dio before extending aio write submission

It launches four adjacent 1k IOs past EOF, then reads back
to see if we have 4k worth of the data we wrote, or something else -
possibly zeros from sub-block zeroing and eof racing.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: fix merge errors in fuzzer tests

Fix some merge errors when the fuzzer tests went in.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: _require_dm_target() helper

generic/085 was failing on a machine w/o devicemapper kernel
support because it requires the linear target, but didn't
explicitly test for it.

I could have cut & pasted _require_dm_linear(), but chose
to go the route of a generic helper, _require_dm_target $FOO,
because some day someone will need the zero target, the error
target, or who knows.

Add the helper, use it in test generic/085, and convert
_require_dm_flakey, _require_dm_snapshot, and
_dmerror_required with this new helper.

Reported-by: Angelo Dureghello <angelo.dureghello@nomovok.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test read corruption of compressed extents differently

Regression test for file read corruption when using compressed extents
that represent file ranges with a length that is a multiple of 16 pages
and that are shared by multiple consecutive ranges of the same file.

This is similar to the test added in commit 694db0c050d6 ("btrfs: read
corruption of compressed extents"), but tests the special case where the
extent's uncompressed length is a multiple of 16 pages. The first btrfs
fix, tested by the test added in the commit mentioned before, failed to
address this special case.

This btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: update fix for read corruption of compressed and shared extents"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: incremental send after replacing a file

Test that an incremental send works after a file from the parent snapshot
gets replaced in the send snapshot by another one at the same exact
location, with the same name and with the same inode number.

This test used to fail after the linux kernel commit 8b191a684968
("Btrfs: incremental send, check if orphanized dir inode needs delayed
rename") and it's fixed by patch titled:

  "Btrfs: send, fix corner case for reference overwrite detection"

Signed-off-by: Martin Raiber <martin@urbackup.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: add test for quota groups and drop snapshot

Test btrfs quota group consistency operations during snapshot
delete. Btrfs has had long standing issues with drop snapshot
failing to properly account for quota groups. This test crafts
several snapshot trees with shared and exclusive elements. One of
the trees is removed and then quota group consistency is checked.

This issue is fixed by the following linux kernel patches:
   Btrfs: use btrfs_get_fs_root in resolve_indirect_ref
   Btrfs: keep dropped roots in cache until transaciton commit
   btrfs: qgroup: account shared subtree during snapshot delete

Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: Fix _filter_uuid golden output for device replace tests

As a workaround for a regression in the uuid filter introduced by
a092363bbdfa ("xfs: test changing UUID on V5 superblock"), the btrfs
100 and 101 tests included an extra white space before the uuid in their
golden output files. However commit 48613832ad11 ("_filter_uuid: Fix
output regression for btrfs/006"), which came later, fixed the regression
in the uuid filter therefore making btrfs/100 and btrfs/101 fail due to
the extra space in their expected golden output files. So just remove the
extra white spaces from the golden output files.

  $ ./check btrfs/100
  FSTYP         -- btrfs
  PLATFORM      -- Linux/x86_64 debian3 4.2.0-rc5-btrfs-next-13+
  MKFS_OPTIONS  -- /dev/sdc
  MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

  btrfs/100 4s ... - output mismatch (see .../results//btrfs/100.out.bad)
    --- tests/btrfs/100.out 2015-09-22 02:56:35.031470334 +0100
    +++ /home/fdmanana/git/hub/xfstests/results//btrfs/100.out.bad...
    @@ -1,10 +1,10 @@
     QA output created by 100
    -Label: none  uuid:  <UUID>
    +Label: none  uuid: <UUID>
      Total devices <NUM> FS bytes used <SIZE>
      devid <DEVID> size <SIZE> used <SIZE> path SCRATCH_DEV
      devid <DEVID> size <SIZE> used <SIZE> path /dev/mapper/error-test

    (...)
  Failures: btrfs/100
  Failed 1 of 1 tests

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/109: fix status on completion

My fault. I didn't set status=0 when removing the filesystem
checking code from Jan's original test code in commit ed2732f
("fstests: Add test of rename").

Signed-off-by: Dave Chinner <dchinner@redhat.com>

generic/014: Fix wrong return value in output

Current code always output "truncfile returned 0" because $? was
modified by previous command. Use $ret to indicate the correct
return value from truncfile.

[dchinner: fix formatting issues, update commit message.]

Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/199: fix breakage every time mkfs defaults change.

From v3.2.4 onwards, mkfs.xfs defaults to enabling ftype, which
causes xfs/199 to break again. Change the test to store the
features2 fields value and compare that directly against the
bad_features2 value which should be the same.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/167: remove duplicated _require_fs_space

Seems the same patch was applied twice,

6f55bbd xfs/167: need at least 10GB of scratch space to run
b50473c xfs/167: need at least 10GB of scratch space to run

and there're two _require_fs_space calls in the test, remove one.

Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: read corruption of compressed extents

Regression test for file read corruption when using compressed extents
that are shared by multiple consecutive ranges of the same file.

The btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: fix read corruption of compressed and shared extents"

Without the corresponding fix the test fails because the second time it
reads the test files it gets different data (some pages are incorrectly
filled with zeroes) from the data it wrote before doing a clean ummount.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: ENOSPC test for a btrfs

Regression test for an ENOSPC issue when attempting to write to a file in
a filesystem without any data block groups allocated.

The btrfs issue is fixed by the linux kernel patch titled
"Btrfs: don't initialize a space info as full to prevent ENOSPC" and the
regression was introduced by the patch titled
"Btrfs: fix block group ->space_info null pointer dereference".

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

src/t_truncate_cmtime: test truncate up too

Currently src/t_truncate_cmtime only tests the truncate down case,
truncate up case should be tested too. A recent ext4 bug shows that we
missed that coverage.

See kernel commit 911af577de4e ("ext4: update c/mtime on truncate up")

Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test device delete with EIO on src dev

This test case tests if the device delete works with
the failed (EIO) source device. EIO errors are achieved
usign the DM device.

This test would need following btrfs-progs and btrfs
kernel patch
   btrfs-progs: device delete to accept devid
   Btrfs: device delete by devid

However when btrfs-progs patch is not found this test will
not run, and when kernel patch is not found btrfs-progs
will fail gracefully and thus the test script.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test device replace, with EIO on the src dev

This test case will test to confirm the replace works with
the failed (EIO) replacing source device. EIO condition is
achieved using the DM device.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

dm-error: add functions to create dm-error device

Controlled EIO from the device is achieved using the dm device.
Helper functions are at common/dmerror.

Broadly steps will include calling _dmerror_init().
_dmerror_init() will use SCRATCH_DEV to create dm linear device and assign
DMERROR_DEV to /dev/mapper/error-test.

When test script is ready to get EIO, the test cases can call
_dmerror_load_table() which then it will load the dm error.
so that reading DMERROR_DEV will cause EIO. After the test case is
complete, cleanup must be done by calling _dmerror_cleanup().

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: test partial block device failure

Calls like fsync() should report failure on partial I/O failure, e.g. a
single failed disk in a raid 0 stripe.

This test is motivated by an XFS bug, and this commit fixed the issue
xfs: return errors from partial I/O failures to files

This case is written by David Jeffery <djeffery@redhat.com> originally.

Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/067: Add a missing symlinks requirement

Signed-off-by: Ari Sundholm <ari@tuxera.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fstests: btrfs: Add reserved space leak check for rewrite dirty page

Btrfs qgroup reserve codes lacks check for rewrite dirty page, causing
every write, even rewriting a uncommitted dirty page, to reserve space.

But only written data will free the reserved space, causing reserved
space leaking.

The bug exists almost from the beginning of btrfs qgroup codes, but
nobody found it.

For example:

1)Write [0, 12K) into file A
  reserve 12K space

File A:
0 4K 8K 12K
|<--------dirty-------->|
reserved: 12K

2)Write [0,4K) into file A
0 4K 8K 12K
|<--------dirty-------->|
reserved: 16K <<< Should be 12K

3) Commit transaction
Dirty pages [0,12) written to disk.
Free 12K reserved space.
reserved: 4K <<< Should be 0

This testcase will test such problem.
Kernel fix will need some huge change, so won't be soon.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>

compat: use stat -c instead of stat --format

For busy-box systems that don't support the extended format options.

Signed-off-by: Ari Sundholm <ari@tuxera.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

new: Add seqres.full cleanup to template

Add cleanup for seqres.full for new test case template, as sometimes
new testcase may forgot to cleanup seqres.full.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>

fstests: Add test of rename

Test renaming of various entry types in directories of various sizes.
Check that filesystem didn't get corrupted.

[dchinner: fixed missing bits from new test template, removed
 checking of scratch as harness does that. ]

Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/077: fix test for userspace meta_uuid support

The current _require_meta_uuid() test looks for a failure return
code from xfs_db -x -c "uuid generate" but in fact this exits
with success.  (In fact uuid_f always exits with success; perhaps
this needs fixing, but that's in the wild now).

So grep for the string(s) stating that it failed, instead.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4/305: reduce runtime by limiting mount/umount cycles

ext4/305 sleeps 3 minutes and does mount/umount loop in background,
which produces lots of logs in dmesg and 3 minutes is not necessary.

Ted pointed out that 30 mount/umount cycles is enough to crash a buggy
kernel, so just limit the mount/umount loop to reduce the runtime. And
now the runtime is about 2s.

Reported-by: Theodore Ts'o <tytso@mit.edu>
Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

_filter_uuid: Fix output regression for btrfs/006

_filter_uuid() get updated and changed output from:
 uuid: <UUID>
 ->
 uuid:  <UUID>

It is a typo introduced by xfs/077, this patch fixed this.

Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: fsync after extent cloning

Test that if we fsync a file that got one extent partially cloned into a
lower file offset, after a power failure our file has the same content it
had before the power failure and after the extent cloning operation.

This test is motivated by an issue found in btrfs that is fixed by the
linux kernel patch titled:

  "Btrfs: fix file read corruption after extent cloning and fsync"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/194: fix the exception when run on 4k sector drives

The below command in "Test 4":

    xfs_io -c "pwrite -S 0x33 -b 512 `expr $blksize \* 2` 512"

will run failed on 4k sector drives. So I use sector size to
replace the hard-code 512.

And we won't run this case when $sector_size > $page_size / 8.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/201: use min_dio_alignment size to replace 512b

This case use hard-code 512, but in 4k sector size device,
it will fail.

So I call _min_dio_alignment() to get the sector size, then
replace `512`.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: use -f option for xfs_repair a fs image

xfs/020 need -f option, or it'll be fail on 4k sector device.

Add -f option for xfs/032 for safe and better.

There're some cases use _check_xfs_filesystem(), or others
function which call this function to check a regular file.
That's will fail when the regular file on a 4k sector device.
For example xfs/250.

So I change _check_xfs_filesystem(), add -f option to xfs_repair,
when the $device is a file.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/084: use src/multi_open_unlink to replace tail command

generic/084 try to run 'tail' command, tail will use inotify.
There're some limit about the number of inotify. For example
fs.inotify.max_user_instances specifies an upper limit on
the number of inotify instances that can be created per real
user ID.

When I test on a machine with 154 cpu cores, this case run
failed, and hit many warning likes:

    +tail: inotify cannot be used, reverting to polling: Too many open files

Because the fs.inotify.max_user_instances is 128, so if we
try to tail 154 files, it will be failed.

So use src/multi_open_unlink to instead of tail will avoid
this problem.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: test file/symlink metadata corruption checking and repair

Targeted fuzzing tests which destroy various pieces of file and
symlink metadata; the tests look for (a) kernel detection of
corruption, (b) xfs_repair repair of said corruption, and (c)
post-repair fs usability.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: test directory metadata corruption checking and repair

Targeted fuzzing tests which destroy various pieces of directory
metadata; the tests look for (a) kernel detection of corruption, (b)
xfs_repair repair of said corruption, and (c) post-repair fs
usability.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: test allocation group metadata corruption checking and repair

Targeted fuzzing tests which destroy various pieces of filesystem or
allocation group metadata; the tests look for (a) kernel detection of
corruption, (b) xfs_repair repair of said corruption, and (c)
post-repair fs usability.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4: test file/dir/symlink metadata corruption checking and repair

Targeted fuzzing tests which destroy various pieces of file,
directory, and symlink metadata; the tests look for (a) kernel
detection of corruption, (b) e2fsck repair of said corruption, and (c)
post-repair fs usability.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4: test block group metadata corruption checking and repair

Targeted fuzzing tests which destroy various pieces of filesystem or
block group metadata; the tests look for (a) kernel detection of
corruption, (b) e2fsck repair of said corruption, and (c) post-repair
fs usability.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fuzz: randomly fuzz XFS and ext4 filesystems

Introduce tests for XFS and ext4 which format a filesystem, populate
it, then uses blocktrash and e2fuzz to corrupt the metadata.  The FS
is remounted, modified, and unmounted.  Following that, xfs_repair or
e2fsck are run until it no longer finds errors to correct, after which
the FS is mounted yet again and exercised to see if there are any
errors remaining.

The XFS test requires an xfs_db that can handle blocktrash and v5
filesystems.

The ext4 test requires metadata_csum support in e2fsprogs.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: add routines to fuzz filesystems

Create common/populate with routines to support the new fuzz tests.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/074: specify filesystem size in terms of size not block count

When testing 512 block size xfs, xfs/074 fails as

   QA output created by 074
  +fallocate: No space left on device
   Silence is golden

That's because 40051712*512=20G < 30G.

And quote from Dave:

  That was sized to give AGs of a specific size, which originally
  contributed to the problem being exposed. You should change the block
  count specification to a size specification so the filesysetm being
  made on 4k block size filesystems remains unchanged.

  size    = 40051712b
          = 40051712 * 4096
          = 164,051,812,352
          = 156452m

So set the filesystem size to 156452m explicitly.

Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/064: allow room for unexpected allocation behavior

Per Dave Chinner's suggestion, modify generic/064 so that it won't fail
if it finds a few more extents than it expects in its test file after
inserting ranges.  When 064's test file is first created, some file
systems may use more than the ideal minimum single extent to represent
it, and this can lead to a mismatch between the actual and expected
extent count after the ranges have been inserted.  Ext4 file systems
mounted with delayed allocation disabled can exhibit this behavior
if a test file's blocks happen to be allocated across regions of file
system metadata.

Also, replace the open coded counting of extents and holes with a
simpler call to _count_extents(), and clarify some comments.

Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/042: reduce runtime of the test

xfs/042 is really an xfs_fsr test, and it only writes about 60MB of
data. however, because it is trying to write lots of data in ENOSPC
conditions, it can take a long time as XFS does flushes to maximise
space usage at ENOSPC. e.g. on a slow 1p VM:

 xfs/042 426s ... 425s

It takes a long time to write a small amount of data. To avoid this
slow flushing problem, create the fragmented files with fallocate()
rather than write(), which fails much faster as there is no dirty
data to flush before retrying the allocation and failing. THis
results in:

 xfs/042 425s ... 11s

A massive reduction in runtime, such that we can consider putting
xfs/042 into the quick group....

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: fsync files with multiple links

Test that when we have a file with multiple hard links belonging to
different parent directories, if we remove one of those links, fsync the
file using one of its other links (that has a parent directory different
from the one we removed a link from), power fail and then replay the
fsync log/journal, the hard link we removed is not available anymore and
all the filesystem metadata is in a consistent state.

This test is motivated by an issue found in btrfs, where the test fails
with:

  generic/107 2s ... - output mismatch (see .../results/generic/107.out.bad)
    --- tests/generic/107.out 2015-08-04 09:47:46.922131256 +0100
    +++ /home/fdmanana/git/hub/xfstests/results//generic/107.out.bad
    @@ -1,3 +1,5 @@
     QA output created by 107
     Entries in testdir:
     foo2
    +foo3
    +rmdir: failed to remove '/home/fdmanana/btrfs-tests/scratch_1/testdir': Directory not empty
    ...
    (Run 'diff -u tests/generic/107.out .../generic/107.out.bad'  to see the entire diff)
  _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent (see .../generic/107.full)
  _check_dmesg: something found in dmesg (see .../generic/107.dmesg)

  $ cat /home/fdmanana/git/hub/xfstests/results//generic/107.full
  _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
  *** fsck.btrfs output ***
  checking extents
  checking free space cache
  checking fs roots
  root 5 inode 257 errors 200, dir isize wrong
unresolved ref dir 257 index 3 namelen 4 name foo3 filetype 1 \
          errors 5, no dir item, no inode ref

  $ cat /home/fdmanana/git/hub/xfstests/results//generic/107.dmesg
  (...)
  [188897.707311] BTRFS info (device dm-0): failed to delete reference to \
    foo3, inode 258 parent 257
  [188897.711345] ------------[ cut here ]------------
  [188897.713369] WARNING: CPU: 10 PID: 19452 at fs/btrfs/inode.c:3956 \
    __btrfs_unlink_inode+0x182/0x35a [btrfs]()
  [188897.717661] BTRFS: Transaction aborted (error -2)
  (...)
  [188897.747898] Call Trace:
  [188897.748519]  [<ffffffff8145f077>] dump_stack+0x4f/0x7b
  [188897.749602]  [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
  [188897.750682]  [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
  [188897.751936]  [<ffffffffa04c5d09>] ? __btrfs_unlink_inode+0x182/0x35a [btrfs]
  [188897.753485]  [<ffffffff8104b410>] warn_slowpath_fmt+0x46/0x48
  [188897.754781]  [<ffffffffa04c5d09>] __btrfs_unlink_inode+0x182/0x35a [btrfs]
  [188897.756295]  [<ffffffffa04c6e8f>] btrfs_unlink_inode+0x1e/0x40 [btrfs]
  [188897.757692]  [<ffffffffa04c6f11>] btrfs_unlink+0x60/0x9b [btrfs]
  [188897.758978]  [<ffffffff8116fb48>] vfs_unlink+0x9c/0xed
  [188897.760151]  [<ffffffff81173481>] do_unlinkat+0x12b/0x1fb
  [188897.761354]  [<ffffffff81253855>] ? lockdep_sys_exit_thunk+0x12/0x14
  [188897.762692]  [<ffffffff81174056>] SyS_unlinkat+0x29/0x2b
  [188897.763741]  [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
  [188897.764894] ---[ end trace bbfddacb7aaada8c ]---
  [188897.765801] BTRFS warning (device dm-0): __btrfs_unlink_inode:3956: \
    Aborting unused transaction(No such entry).

Tested against ext3/4, xfs, reiserfs and f2fs too, and all these
filesystems currently pass this test (on a 4.1 linux kernel at least).

The btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: fix stale dir entries after removing a link and fsync".

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/038: speed up file creation

Now that generic/038 is running on my test machine, I notice how
slow it is:

generic/038      692s

11-12 minutes for a single test is way too long.
The test is creating
400,000 single block files, which can be easily parallelised and
hence run much faster than the test is currently doing.

Split the file creation up into 4 threads that create 100,000 files
each. 4 is chosen because XFS defaults to 4AGs, ext4 still has decent
speedups at 4 concurrent creates, and other filesystems aren't hurt
by excessive concurrency. The result:

generic/038      237s

on the same machine, which is roughly 3x faster and so it (just)
fast enough to to be considered acceptible.

[Eryu Guan: reduced number of files to minimum needed to reproduce
 btrfs problem reliably, added $LOAD_FACTOR scaling for longer
 running.]

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4/005: add missing out file back

ext4/005.out is missing, add it back.

Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfstests: fix build errors and warnings

After upgrading userspace on test machines to xfsprogs-4.2.0-rc1,
lots of build warnings and failures are exposed from implicit
includes that no longer exist. Hence these need fixing to allow
fstests to build correctly.

gcc also seems to have grown new stupidities around uninitialised
variables, so fix them while touching the same files.

Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/038: mount scratch before checking it

We want to check the size of scratch with _require_fs_space,
but we have to mount it firstly.

Reported-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test for incremental send after file extent cloning

Test that an incremental send works after a file gets one of its extents
cloned/deduplicated into lower file offsets.

This is a regression test for the problem fixed by the linux kernel patch
titled:

  "Btrfs: teach backref walking about backrefs with underflowed
   offset values"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: fix _count_extents and _count_holes

In _count_extents and _count_holes, the output of 'xfs_io -c "fiemap"'
is saved in var res, but the following "echo $res" will merge the
original output into one line. e.g.

0: [0..63]: 96..159
1: [64..127]: hole

will be

0: [0..63]: 96..159 1: [64..127]: hole

so the extent count is always 0 if there's a hole.

This makes generic/046 fail occasionally. (Seems it's easier to
reproduce when the system is under some presure, e.g. with fsstress
running.)

Tested the new _count_extents and _count_holes with generic/04[3-9] and
tests all passed as expect.

Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

locktest: remove manual declaration of errno

locktest.c has already #included <errno.h>, so remove the unneeded
(and in some cases, incorrect) manual declaration of errno as an
integer.  Some C libraries use a macro to provide thread-safety for
errno, so it's incorrect to try to provide a manual declaration.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>

lstat64:: use Posix st_mode defines

Instead of the  obsolete SysV S_IEXEC, S_IREAD, and S_IWRITE, use
the Posix defines of S_I[WRX]{OTH,GRP,USR}.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>

check: Fix a typo

Fix the spelling of 'Argments' -> 'Arguments'.

Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: file fsync after unlink and inode eviction

Test that if we remove one hard link from an inode, evict the inode,
fsync the inode, power fail and then mount the filesystem, the hard
link we removed does not exists anymore and the filesystem metadata
is in a consistent state.

This test is motivated by an issue found on btrfs, and on an unpatched
btrfs it fails with:

  FSTYP         -- btrfs
  PLATFORM      -- Linux/x86_64 debian3 4.1.0-rc6-btrfs-next-11+
  MKFS_OPTIONS  -- /dev/sdc
  MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

  generic/098 4s ... - output mismatch (see .../generic/098.out.bad)
    --- tests/generic/098.out 2015-07-23 18:01:12.616175932 +0100
    +++ .../generic/098.out.bad 2015-07-23 18:04:58.924138308 +0100
    @@ -1,3 +1,6 @@
     QA output created by 098
     Entries in testdir:
    +bar
     foo
    +rm: cannot remove '.../testdir/foo': Stale file handle
    +rmdir: failed to remove '.../scratch_1/testdir': Directory not empty
    ...
  _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent ...
  (...)

  $ cat /home/fdmanana/git/hub/xfstests/results/generic/098.full
  (...)
  checking fs roots
  root 5 inode 258 errors 2001, no inode item, link count wrong
   unresolved ref dir 257 index 0 namelen 3 name foo filetype 1 errors 6,\
       no dir index, no inode ref
   unresolved ref dir 257 index 3 namelen 3 name bar filetype 1 errors 5,\
       no dir item, no inode ref
  (...)

Tested against ext3/4, xfs, f2fs and reiserfs.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs/011: test replace on RAID 5/6 now that it's supported

btrfs replace has been supported on RAID 5/6 since Linux 3.19.

Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

check: add a flag for direct printing of test output

Add -d debug dump flag to ./check to directly print a test output
to stdout, instead of just saving it into a file and showing a diff
snippet.

Useful e.g. when writing a new test.

Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

check: Allow partial test names

When running ./check and calling a test with a name, id is enough
to find the test (names added in 03c633bf).

If the full test path is tests/xfs/123-foo-bar, then all these
invocations should work, as long as the given part of the test name
is valid and the three-digits id is here.

./check xfs/123-foo-bar
./check xfs/123-foo
./check xfs/123

Always use full test name in results.

Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/078: omit -m crc=0 mkfs option if mkfs.xfs has no meta support

This basically does the same as in commit

90a3bfc xfs: be compatible with older mkfs.xfs which has no v5 support

which left xfs/078 behind.

Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

check: Make -g and -x option meet description in manual

In manual:
 # ./check --help
 ...
 -g group[,group...] include tests from these groups
 -x group[,group...] exclude tests from these groups
 ...

Above format is not supported, because ',' is not parsed in code.
This patch fixed it.

Before patch:
 # ./check -g scrub,replace
 Group "scrub,replace" is empty or not defined?

After patch:
 # ./check -g scrub,replace
 FSTYP         -- btrfs
 PLATFORM      -- Linux/x86_64 kerneldev 4.2.0-rc2_HEAD_c65b99f046843d2455aa231747b5a07a999a9f3d_+
 MKFS_OPTIONS  -- /dev/vdd
 MOUNT_OPTIONS -- /dev/vdd /var/ltf/tester/scratch_mnt
 ...(right result)...

Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>