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>

xfs: test log recovery checksum with different log buf sizes

XFS had a bug which lead to spurious checksum failures during
verification of log records during recovery. This occurred when the
filesystem was mounted for recovery with a different log buffer size
(via the 'logbsize=...' mount option from when the filesystem crashed.

Create a regression test that dirties the log using one particular log
buffer size, shuts down the fs and attempts recovery using a larger log
buffer size.

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

PATCH 3/3 V6] xfs: test changing UUID on V5 superblock

Tests xfs_db's ability to change & restore UUIDs on V5 filesystems,
and tests xfs_copy's ability to change the UUID on the copy.

Update to _filter_uuid is so that it will catch the UUID output
from xfs_admin -u, which is slightly different than the regexp it
was expecting.

This requires new userspace which knows how to change the UUID on
a V5 superblock.

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

generic: test for fsync after adding hard links

Test that if we add hard links (in the same directory) to two files and
then fsync only one of the files, after the fsync log/journal is replayed
all the links exist and the filesystem metadata (directory and file
inodes) is in a consistent state.

This test is motivated by a bug found in btrfs that is fixed by linux
kernel patch titled:

  "Btrfs: fix stale directory entries after fsync log replay"

Verified against ext3/4, xfs, f2fs and reiserfs on a 4.1 linux kernel.

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

btrfs: regression test for the clone ioctl

This tests that we can not clone an inline extent into a non-zero file
offset. Inline extents at non-zero offsets is something btrfs is not
prepared for and results in all sorts of corruption and crashes on
future IO operations, such as the following BUG_ON() triggered by the
last write operation done by this test:

  [152154.035903] ------------[ cut here ]------------
  [152154.036424] kernel BUG at mm/page-writeback.c:2286!
  [152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  (...)
  [152154.036424] RIP: 0010:[<ffffffff8111a9d5>]  [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90
  (...)
  [152154.036424] Call Trace:
  [152154.036424]  [<ffffffffa04e97c1>] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs]
  [152154.036424]  [<ffffffffa04ea82c>] __btrfs_buffered_write+0x245/0x4c8 [btrfs]
  [152154.036424]  [<ffffffffa04ed14b>] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs]
  [152154.036424]  [<ffffffffa04ed15a>] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs]
  [152154.036424]  [<ffffffffa04ed2c7>] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs]
  [152154.036424]  [<ffffffff81165a4a>] __vfs_write+0x7c/0xa5
  [152154.036424]  [<ffffffff81165f89>] vfs_write+0xa0/0xe4
  [152154.036424]  [<ffffffff81166855>] SyS_pwrite64+0x64/0x82
  [152154.036424]  [<ffffffff81465197>] system_call_fastpath+0x12/0x6f
  (...)
  [152154.242621] ---[ end trace e3d3376b23a57041 ]---

This issue is addressed by the following linux kernel patch for btrfs:
"Btrfs: fix file corruption after cloning inline extents".

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test to exercise shared extent reference accounting

Regression test for adding and dropping an equal number of references
for file extents. Verify that if we drop N references for a file extent
and we add too N new references for that same file extent in the same
transaction, running the delayed references (which always happens at
transaction commit time) does not fail.

The regression was introduced in the 4.2-rc1 Linux kernel and fixed by
the patch titled: "Btrfs: fix order by which delayed references are run".

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/015: keep create_file running until growfs finished

create_file may run over before growfs, which depends on many reasons. such as
the schedule algorithm, the workload of testing machine, etc. we should always
make sure the create_file run over after growfs, then we can get the valid
result of this test.

Signed-off-by: George Wang <xuw2015@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4: test migration to non-extent based file format

On unpatched kernel, converting file with a hole at the beginning to
non-extent based format results in ext4 i_blocks corruption. Add a new
regression test case for it.

These two commits fixed the corruption:
ext4: be more strict when migrating to non-extent based file
ext4: correctly migrate a file with a hole at the beginning

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

generic: xattr enospc cleanup test

XFS had a regression where inode reclaim in the unlink codepath would
not correctly tear down extended attribute forks where no xattr extents
are present. Add a generic test to create this condition.

The test sets extended attributes on a series of files under ENOSPC
conditions and then verifies that the files can be removed without
syslog warnings or errors.

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

generic: busy loop of dd and rm test

Add a case for testing whether writing failed on NO_SPACE in a busy
loop of write and delete when disk almost full.  It is a long-term
problem since very beginning in btrfs, and has been fixed by
patchset titled "btrfs: Fix no_space on dd and rm loop" from
zhaolei@cn.fujitsu.com.

Signed-off-by: Wang Yanfeng <wangyf-fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: test for fsync after file truncations

Test that if we truncate a file to a smaller size, then truncate it to
its original size or a larger size, then fsyncing it and a power failure
happens, the file will have the range [first_truncate_size, last_size[
with all bytes having a value of 0x00 if we read it the next time the
filesystem is mounted.

This test is motivated by a bug found in btrfs, which is fixed by a patch
titled: "Btrfs: fix fsync after truncate when no_holes feature is enabled"

Tested against ext3/4, xfs, btrfs (with and without the fix, and with the
no_holes feature disabled), f2fs, reiserfs and nilfs2.

All filesystems pass the test except for unpatched btrfs with the
no_holes feature enabled (as expected) and f2fs. Both produce the
following file contents that differ from the golden output:

  File foo content after log replay:
  0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
  *
  0200000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
  *
  0372000
  File bar content after log replay:
  0000000 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee
  *
  0200000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  *
  0372000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  *
  0772000

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

generic: test for truncating a file into the middle of a hole

Test that after truncating a file into the middle of a hole causes the
new size of the file to be persisted after a clean unmount of the
filesystem (or after the inode is evicted). This is for the case where
all the data following the hole is not yet durably persisted, that is,
that data is only present in the page cache.

This test is motivated by an issue found in btrfs, which got fixed by
the patch titled:

  "Btrfs: fix shrinking truncate when the no_holes feature is enabled"

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

fstests: remove $seqres.full before tests run

Some tests append logs to $seqres.full and never remove the log, which
keeps the log file growing. Remove $seqres.full before test in
following tests:

   ext4/271
   generic/019
   generic/269
   generic/270
   shared/272

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

generic: test zero range crossing isize within single block

Exercise the situation that cause ext4 to BUG_ON() when we use
zero range to zero a range which starts within the isize but ends
past the isize but still in the same block. This particular problem
has only been seen on systems with page_size > block_size.

This tests exercises the problem fixed in kernel with commit
0f2af21aae11972fa924374ddcf52e88347cf5a8
ext4: Allocate entire range in zero range

Signed-off-by: Lukas Czerner <lczerner@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: concurrent IO test with mixed IO types

Test concurrent buffered I/O, DIO, AIO, mmap I/O and splice I/O on the
same files.

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

common: add filter to _check_dmesg

Introduce a parameter to _check_dmesg which allows callers to provide a
customized filter function to filter out intentional dmesg logs. The
default filter is a simple 'cat' command.

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

common: move _check_dmesg to common/rc

Move _check_dmesg to common/rc so that tests could call it directly.

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

generic: add fiemap test that does prealloc

I noticed that btrfs wasn't setting unwritten on prealloc test, and then
subsequently noticed that we weren't testing fiemap on prealloc extents with the
fiemap-tester.  This patch adds another test that does the same as generic/225
only with prealloc enabled.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fiemap-tester: convert to use O_DIRECT

We want to test fiemap, so we want to lay out a file exactly a certain way.  XFS
tries to be smart and will allocate data in a hole if the write pattern is

[data][hole][data]

where the hole is small enough.  This screws with fiemap-tester sometimes, so
make it easy and just do O_DIRECT so that we get the layout we want and can get
back to testing fiemap.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

shared: test for fsync after adding xattrs to a file

This test is motivated by an issue found in btrfs.

It test that after syncing the filesystem, adding many xattrs to a file,
syncing the filesystem again, writing to the file and then doing a fsync
against that file, all the xattrs still exists after a power failure.
That is, after the fsync log/journal is replayed, the xattrs still exist
and with the correct values.

The btrfs issue is fixed by the patch titled:

  "Btrfs: fix fsync xattr loss in the fast fsync path"

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

generic: test for fsync after adding hard link to a file

This test is motivated by an issue found in btrfs.

It tests that after syncing the filesystem, adding a hard link to a file,
syncing the filesystem again, doing a write to the file that increases
its size and then doing a fsync against that file, durably persists the
data written to the file. That is, after log/journal replay, the data
is available.

The btrfs issue is fixed by the commit titled:

  "Btrfs: fix fsync data loss after append write"

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

awk invocation cleanup for busybox support.

These changes make it possible to run more of the tests on busybox.

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

btrfs: test premature submount unmounting when deleting default subvolume

Add a regression test for a problem where attempting to delete the
default subvolume would fail (as expected), but not until after all
submounts under the subvolume were unmounted.

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

xfs: test inode allocation with fragmented free space

XFS dynamic inode allocation has a fundamental limitation in that an
inode chunk requires a contiguous extent of a minimum size. Depending on
the level of free space fragmentation, inode allocation can fail with
ENOSPC where the filesystem might not be near 100% usage.

The sparse inodes feature was implemented to provide an inode allocation
strategy that maximizes the ability to allocate inodes under free space
fragmentation. This test fragments free space and verifies that
filesystems that support sparse inode allocation can allocate a minimum
percentage of inodes on the fs.

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

btrfs/022: add a quota rescan -w to wait rescan finished.

When we enable quota, btrfs will rescan quota numbers. We need
to wait the rescan finished before any more operations on btrfs
qgroups. Otherwith, the new btrfs-progs would WARN out:

WARNING: Rescan is running, qgroup data may be incorrect.

It would make btrfs/022 failed.

Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: test rw remount on norecovery ro mount

Commit bbe051c841d5 ("xfs: disallow ro->rw remount on norecovery mount")
disabled rw remount on norecovery ro mount, this test makes sure the
behavior is correct.

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

generic/081: wait for lv to be settled before creating fs on it

Call 'udevadm settle' or 'udevsettle' or 'sleep 1' to make sure new lv
is ready for use before making filesystem on it, depends on which
command is available on the system.

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

generic/288: correct the testcase description

The testcase tests 2 corner cases:
    Length is zero
    Length is smaller than block size
Correct the beginning description by changing "of" to "or".

Signed-off-by: Wang Sheng-Hui <shhuiw@foxmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: test extent size hint size overflows

In certain cases, the extent size hints can cause maximum extent
size overflows resulting in extent tree corruptions. This test
exercises the original reproducer, and another corner case
demonstrated to expose problems on 1k block size filesystems.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
--
Version 2:
- TESTDIR->TEST_DIR
- append output to $seqres.full

fsstress: add the -c option

This option causes fsstress to delete the test directory between each
run.  This is the opposite from the ltp version of fsstress, which
deletes the test directory by default, and the -c option caused ltp's
fsstress _not_ to delete the test directory.

It can be useful to be able to have the same test behavior as ltp
version, and although reversing the sense of the option is
unfortunate, it also reserves the -c option, which makes it a bit
easier if we want to eventually have one version which is a superset
of the xfstest and ltp version of fsstress.

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

fsstress: add the [-l loops] option

This feature is in the ltp version of fsstress; port it into
xfstests.

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

config: Fix sysfs paths for partitions

generic/019 was failing with:

./tests/generic/019: line 65: /sys/block/pmem0p2/make-it-fail: No such file or directory

When using a partition, the file needed is located at
/sys/block/pmem0/pmem0p2/make-it-fail.

Rather than attempt to deduce whether a block device is a partition
or not, use the symlinks located in /sys/dev/block/ to find the right
location for the make-it-fail file.

Also change btrfs/088 to use the new _sysfs_dev function.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfstests: correct comment in generic/135

xfs_io '-d' specifies direct IO, not sync IO.

Signed-off-by: Wang Sheng-Hui <shhuiw@foxmail.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: add a test for fallocate+truncate

There was some confused about what the fs was supposed to do when you truncate
at i_size with preallocated space past i_size.  We decided on the following
things

1) truncate(i_size) will trim all blocks past i_size.
2) truncate(x) where x > i_size will not trim all blocks past i_size.

This test is to make sure we're all acting sanely.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>