btrfs: test btrfs send after complex directory hierarchy changes

Test a very complex scenario for a btrfs incremental send operation where a
large directory hierarchy had many subtrees moved between parent directories,
preserving the names of some directories and inverting the parent-child
relationship between some directories (a child in the parent snapshot became
a parent, in the send snapshot, of the directory that is its parent in the
parent snapshot).

This test made the incremental send fail with -ENOMEM because it entered an
infinite loop when building path strings that are used as operands of the
rename operations issued in the send stream.
This issue was fixed by the following linux kernel btrfs patch:

   Btrfs: incremental send, don't delay directory renames unnecessarily

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: _require_command needs to handle parameters

_require_command fails when a parameter based command is passed to
it, such as "xfs_io -F" or "btrfs filesystem defrag" as the command
string does not point at a binary.  Rather than hacking at all the
callers and limiting what we can do with $*_PROGS variables, just
make _require_command handle this case sanely.

Change _require_command to check for one or two variables passed to
it and to fail if none or more than 2 parameters are passed. This
will catch most cases where unquoted parameter-based commands are
passed. Further, for the command variable, the executable we need to
check for is always going to be the first token in the variable.
Hence we can simply ignore everything after the first token for the
purposes of existence and executable checks on the command.

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

generic: LVM and ram disks don't play well

The "brd" kernel ram disk abuses BLKFLSBUF to mean "free all memory
in the ram drive" when in fact it should mean "flush all dirty
buffers to stable storage". The brd driver ignores BLKFLSBUF if
there is an active reference to the block device, (e.g. a fs is
mounted on it), but when a device is layered over the top of it
(e.g. dm-flakey, lvm devices, etc) then the applications and
filesystems hold references to the upper device, not the brd device.
Hence when the upper device passes down BLKFLSBUF to brd, it removes
all the pages in the brd, effectively erasing it.  This causes all
sorts of problems.....

Fix this by black listing "/dev/ramXXX" devices from tests that
require DM in some way. The _requires_sane_bdev_flush() macro is
called by the _requires_dm.... checks so that we don't have to
remember to add this to all new tests that use dm in some way.

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

generic: test full dm snapshot devices

Full DM snapshot devices can return unexpected errors from the
underlying device, and this causes problems for filesystems.  In
particular, xfs used to panic in this test, (fixed by commit 8d6c121
"xfs: fix buffer use after free on IO error"), and on current
4.0-rc3 kernels both ext4 and btrfs trigger WARNINGs.

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

build: Allow alphanumeric test name suffixes

To allow test names to be more descriptive, allow a suffix to be
added to the numeric name of the test.  e.g. a test can be named
"tests/generic/001-some-descriptive-name".

Name suffixes are limited to alphanumeric characters and dash - the
name is always prefixed with an unique id for easy identification
of a specific test. Hence we can still use shorthand forms such as
"generic/001" when referring to a test and be clearly understood.

Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: test that mmap-write updates c/mtime

When using mmap() for file i/o, writing to the file should update
it's c/mtime. Specifically if we first mmap-read from a page, then
memap-write to the same page.

This test was failing for the initial submission of DAX because
pfn based mapping do not have an page_mkwrite called for them.
The new Kernel patches that introduce pfn_mkwrite fixes this test.

Test adapted from a script originally written by Dave Chinner.

Signed-off-by: Omer Zilberberg <omzg@plexistor.com>
Signed-off-by: Boaz Harrosh <boaz@plexistor.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test cloning of zero length ranges

Test cloning a file range with a length of zero into a destination offset
greater than zero.

This made btrfs create an extent state record with a start offset greater than
the end offset, resulting in chaos such as an infinite loop when evicting an
inode.

This issue was fixed by the following linux kernel patch:

   Btrfs: fix inode eviction infinite loop after cloning into it

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: fix _filter_mkfs regression

5e8b9e6 btrfs: add regression test for remount with thread_pool resized

did weird things to _filter_mkfs; aside from broken indentation,
it also short-circuited the default non-xfs behavior, which was to
emit a default block & inode size.  And that was all because btrfs/082
was using _filter_mkfs & not redirecting output away as per normal.

Granted, it's not super clear that _filter_mkfs serves this rather
unique purpose, but anyway...

And, while having this default seems to be of questionable value,
not emitting *anything* led to this on btrfs:

    +./tests/generic/204: line 76: space / (isize + dbsize): division by 0 (error token is ")")

because those variables don't get set for btrfs, thanks to the
above commit.

So take out the use of _filter_mkfs in btrfs/082, and take out the
munging of _filter_mkfs which broke generic/204, and get things back
to something semi-sane.

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

btrfs: test orphan item cleanup

This test tests three conditions where orphan items need to be
cleaned up:

1) Default subvolume is fs tree root (mkfs default)
2) Default subvolume has been set explicitly to another subvolumei
   (set-default)
3) Looking up a subvolume during a traversal

In the kernel, these three cases use separate mechanisms to look up
the subvolumes. There was a bug in the kernel where case #2 wasn't
getting handled and so orphan items would never be cleaned up if the
default subvolume was explicitly set. This issue was fixed with the
upstream commit: btrfs: cleanup orphans while looking up default
subvolume.

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

filter: btrfs-progs subvolume delete output changed

btrfs has started emitting new information from
cmd_subvol_delete(), so filter that out or it breaks btrfs/001:

    -Delete subvolume 'SCRATCH_MNT/snap'
    +Delete subvolume (no-commit): 'SCRATCH_MNT/snap'

(Spell "transaction" correctly while we're at it.)

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

filter: btrfs-progs keeps changing version string

The btrfs cmd now sometimes emits "btrfs-progs" not "Btrfs-progs"
as it used to, so update the filter accordingly.

(This fixes a failure on btrfs/006 w/ btrfs-progs v3.19)

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 incremental send/receive

Test for incremental send where the difference between the parent and
send snapshots is that for a subtree with the same path in both snapshots
(p1/p2), the root directories were swapped.

This issue was fixed by the following linux kernel btrfs patch:

  Btrfs: incremental send, clear name from cache after orphanization

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: test incremental send with directory renames

Test for incremental send where the difference between the parent and
child snapshots is that a directory A was renamed and a directory B was
renamed to the name directory A had before (in the parent snapshot),
but directory A's rename must happen before some other directory C is
renamed.

This issue was fixed by the following linux kernel btrfs patch:

  Btrfs: incremental send, don't rename a directory too soon

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: test fsync after moving files across directories

Test file A fsync after moving one other unrelated file B between
directories and fsyncing B's old parent directory before fsyncing
the file A. Check that after a crash all the file A data we fsynced
is available.

This test is motivated by an issue discovered in btrfs which caused
the file data to be lost (despite fsync returning success to user
space). That btrfs bug is fixed by the following linux kernel patch:

   Btrfs: fix data loss in the fast fsync path

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

generic: add test for truncate/collapse range race

This case tests truncate/collapse range race. If the race occurs, it
will trigger a BUG_ON(). And this kernel patch has fixed this race:
    23fffa9 fs: move falloc collapse range check into the filesystem methods

Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Signed-off-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/077: add missing _require_scratch

generic/077 uses $SCRATCH_DEV without _require_scratch. Add it back.

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

xfs/014: replace df with $DF_PROG

I've seen xfs/014 fails as

[root@dhcp-66-86-3 xfstests]# diff -u tests/xfs/014.out /var/lib/xfstests/results//xfs/014.out.bad

nfs: recognise IPv6 export in _require_scratch_nocheck()

This commit

73dfa4a common: Fixes for testing NFS over IPv6

adds NFS over IPv6 support, and commit

76c5f3c common: re-enable tests that require scratch dev on NFS

enables NFS tests on scratch device.

Now do the same updates to _require_scratch_nocheck() to enable NFS over
IPv6 support on scratch device.

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

generic: test some mount/umount corner cases

There're six test cases:
 - mount at a nonexistent mount point
 - mount a free loop device
 - mount with a wrong fs type
 - umount an symlink to device which is not mounted
 - umount a path with too long name
 - lazy umount a symlink

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

xfs/078: remove loop device on failure

If the test fails for any reason, it fails to tear down the loop
device that was set up and hence the test device cannot be
unmounted, causing failures of subsequent tests.

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

common: fix "utility required warning" with empty utility name

In generic/019, if we hadn't install fio, we will get following output:

 generic/019      [not run]  utility required, skipped this test <- *
 Not run: generic/019
 Passed all 0 tests

When fio is not installed, "$FIO_PROG" is set to blank, and
_require_fio() call _require_command() with none arguments.

This patch fixed all misuse of _require_command(), add 2nd argument
to let _require_command() output right message, and add quotes to
first argument to avoid argument shifting.

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

fstests: generic test for fallocate

Test extent pre-allocation (using fallocate) into a region that already has a
pre-allocated extent that ends beyond the file's size. Verify that if the fs
is unmounted immediately after, the file's size and content are not lost.

This is motivated by a minor issue found in btrfs where the second fallocate
wouldn't update the inode's i_size on disk, fixed by the following btrfs
patch: "Btrfs: add missing inode item update in fallocate()".

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

xfs/073: be quiet about mouting with nouuid option

v4 and v5 xfs generate different outputs because v4 xfs only retries
mount with nouuid option once in the test, v5 xfs tries more times(with
xfs_copy running with -d option).

Just be quiet about mounting with nouuid option, it's much easier than
preparing two different 073.outs and selecting the proper one at runtime

Signed-off-by: Eryu Guan <eguan@redhat.com>

common: append -d option to XFS_COPY_PROG when testing v5 xfs

xfs_copy doesn't work on v5 xfs without -d option, this fails xfs/073
when testing xfs with MKFS_OPTIONS="-m crc=1" set.

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

generic/027: discard mkdir error message

mkdir fails due to ENOSPC occasionally and will fail the whole test.
Redirect stdout and stderr to /dev/null.

Also fix the code style in _cleanup to use single tab.

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

new: fix template for new case to use a single tab not four spaces

So we have preferred code style for all new test cases.

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

generic/065: fsync file 'hello' before checking its content

Explicitly fsync the file named 'hello' before checking its content.
This way there's only one expected result for all filesystems.

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

common: fix a typo in _require_block_device()

We need to check "$1" instead "$SCRATCH_DEV" in this function.

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

generic: Add rudimetary RENAME_WHITEOUT test

There is no API documentation for RENAME_WHITEOUT. There is no
developer documentation for RENAME_WHITEOUT. There are not comments
in the overlayfs or ext4 implementation of RENAME_WHITEOUT.

Hence, this test simply tries to expose basic RENAME_WHITEOUT
behaviour from ext4 so we can reverse-engineer and verify
bug-for-bug renameat2(RENAME_WHITEOUT) ext4 compatibility.

Note: uses generic/078 just to keep out of the way of the 6-7 other
pending new tests.

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

xfs/049: umount -d fails when kernel wins teardown race

When /etc/mtab is linked to /proc/mounts and we are using mount time
created loop devices (i.e. mount -o loop), the unmount can fail
with this amazingly informative error message:

umount: /mnt/scratch/test2: filesystem was unmounted, but mount(8) failed: Invalid argument

What it actually means in this case is that the kernel tore down the
loop device when the last reference went away, and it did it so fast
that mount was not able to find it in /etc/mtab after the unmount
syscall. Hence it could not find the loop device it was supposed to
tear down and has a hissy fit.

This is simple to fix: mount does not need to tear down the loop
device as the kernel does it automatically. Remove the "-d" from
the umount command, and the test passes again.

There's quite a few other tests that also use umount -d - fix them
as well.

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

xfs: don't output mkfs sector sizes into golden output

The mkfs sector sizes are dependent on the underlying device in use,
and so is not fixed. hence it needs to be filtered from any golden
output file, otherwise tests that just differ by sector size will
fail.

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

xfs/104: log size too small for 4k sector drives

xfs/104, xfs/119, xfs/291 and xfs/297 have small fixed log sizes. A
recent change to the kernel ramdisk changed it's physical sector
size from 512B to 4kB, and this results in mkfs calculating a log
size larger than the fixed test size and hence the tests fail.

Change the log size to a larger size that works with 4k sectors, and
also increase the size of the filesystem being created so that the
amount of data space in the filesystem does not change and hence
does not perturb the rest of the test.

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

fstests: generic test for fsync after removing xattrs

This test is motivated by an fsync issue discovered in btrfs.
The issue was that the fsync log replay code did not remove xattrs that
were deleted before the inode was fsynced. The result was unexpected
and differed from xfs and ext3/4 for example.

The btrfs issue was fixed by the following linux kernel patch:

   Btrfs: remove deleted xattrs on fsync log replay

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

fstests: generic test for directory fsync after adding hard links

This test is motivated by an fsync issue discovered in btrfs.
The issue was that after adding a new hard link to an existing file
(one that was created in a past transaction) and fsync'ing the parent
directory of the new hard link, after the fsync log replay the file's
inode link count did not get its link count incremented, while the new
directory entry was visible.
Also, unlike xfs and ext4, new files under the directory we fsync were
not being written to the fsync log, nor were any child directories and
new files and links under the children directories. So this test verifies
too that btrfs has the same behaviour as xfs and ext4.

The btrfs issue was fixed by the following linux kernel patch:

  Btrfs: fix metadata inconsistencies after directory fsync

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

build: add missing files to gitignore

Several binaries show up in git status after running make in a fresh
clone, and so do files introduced by normal usage.

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

create _require_metadata_journaling, and add to tests that need it

Many tests use dm_flakey to trigger log replay, but for filesystems that
don't support metadata journaling, this causes failures when it shouldn't.
(i.e. we can hardly test log replay if there is no log, and the subsequent
filesystem check will turn up errors).

For some tests they actually sync everything we care about, and find
inconsistencies elsewhere, but I erred on the side of simply not running
the test in most cases.

Tested-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs/049: btrfs test, not generic

It's not much fun to run btrfs-specific tests on non-btrfs
filesystems.  ;)

> EXT4-fs (dm-12): Unrecognized mount option "inode_cache" or missing value

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

generic/325: Fix test case to work on 64K page size.

The test case passes 32K as the offset value to msync. This fails on machines
with 64K page size. Fix this by creating a larger file and passing offset
values which are multiples of 64K.

Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fsx: Add fallocate insert range operation

This commit adds fallocate FALLOC_FL_INSERT_RANGE support for fsx.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fsstress: Add fallocate insert range operation

This commit adds insert operation support for fsstress, which is
meant to exercise fallocate FALLOC_FL_INSERT_RANGE support.

[dchinner: turn off this op for xfs/068, which expects an exact
outcome from the fsstress execution. ]

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: Test multiple fallocate insert/collapse range calls

This testcase tests finsert range a single alternate block
multiple times and test merge code of collase range.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: Delayed allocation multi insert

This testcase tests various corner cases with delayed extents and
pre-existing holes for finsert range functionality over different
types of extents.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: Multi insert range tests

This testcase tests various corner cases with pre-existing holes
for finsert range functionality over different type of extents.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: Delayed allocation insert range

This testcase tests various corner cases with delayed extents
for finsert range functionality over different type of extents.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: Simple insert range tests

This testcase tests various corner cases for finsert range
functionality over different type of extents.

Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: test for fsync after punching hole

This test is motivated by an fsync issue discovered in btrfs.
The issue was that after punching a hole for a small range, which
affected only a partial page, an fsync operation would have no effect
at all. This was because for this particular case the btrfs hole
punching implementation did not update some btrfs specific inode
metadata that is required to determine if an fsync operation needs
to update the fsync log. For this to happen, it was also necessary
that in the transaction where the hole punching was performed, and
before the fsync operation, no other operation that modified the file
(or its metadata) was performed.

The btrfs issue was fixed by the following linux kernel patch:

  Btrfs: add missing inode update when punching hole

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

generic: Another fsync after adding hard link test

This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously
fsync'ed successfully, if we end up adding a hard link to our
inode and then persist the fsync log later via an fsync of other
inode for example. This is similar to my previous test, except
that in this test the inode that ends up losing data was created
(with some data) in a transaction different from the one we made
an fsync.

The btrfs issue was fixed by the following linux kernel patch:

   Btrfs: fix fsync data loss after adding hard link to inode

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

generic: add test for fsync after creating hard link

This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously
fsync'ed successfully, if we end up adding a hard link to our
inode and then persist the fsync log later via an fsync of other
inode for example.

The btrfs issue was fixed by the following linux kernel patch:

  Btrfs: fix fsync data loss after adding hard link to inode

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

generic: relocate log recovery tests into tests/generic/

This patch moves the generic testcases defined in xfs into tests/generic/.
  xfs/085 -> generic/052
  xfs/086 -> generic/054
  xfs/087 -> generic/055

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/087: give quota mount option per filesystem

This patch add _get_quota_option to assign the mount option selectively.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common/log: add _get_log_configs for testing options

This patch adds _get_log_configs for xfs and f2fs to test several
mount options for:

  xfs/086
* xfs/087

In xfs/087, one more test was added, so 10 tests will be done in
total.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/086,087: remove specific testing options in output

This patch removes the mkfs and mount options specified in output
files in xfs/086 and xfs/087.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: define _require_logstate

This patch defines logstate by adding dump.f2fs for f2fs's clean and
dirty logs.  This macro is added into:

  xfs/085
  xfs/086
  xfs/087

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: relocate xfs shutdown tests into tests/generic/

This patch moves the generic testcases defined in xfs into
tests/generic/.

  xfs/053 -> generic/042
  xfs/137 -> generic/043
  xfs/138 -> generic/044
  xfs/139 -> generic/045
  xfs/140 -> generic/046
  xfs/179 -> generic/047
  xfs/180 -> generic/048
  xfs/182 -> generic/049
  xfs/200 -> generic/050
  xfs/306 -> generic/051

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: add _require_norecovery

This patch adds checking code whether filesystem supports norecovery
mount option or not.  Use this in the following xfs test.

 xfs/200         (recovery vs ro-block device)

Currently, norecovery mount option is used by xfs only. But some of
log-based filesystems (e.g., f2fs) are able to support it later.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: use fiemap to count extents and holes

For the follwoing tests, this patch adds general script to get extent and
hole counts.

 xfs/137         (data vs filesize)
 xfs/138         (data vs filesize vs truncate)
 xfs/139         (data vs filesize vs partial truncate)
 xfs/140         (data vs filesize vs extending truncate)
 xfs/179         (data vs filesize w/ fsync)
 xfs/180         (data vs filesize w/ sync)
 xfs/182         (data vs filesize w/ recovery)

It also requires these tests to check for fiemap support.

[dchinner: use _require_xfs_io_command "fiemap" for consistency]

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: add _require_scratch_shtudown

This is to detect whether filesystem supports shutdown feature or not.
And let use this into the following xfs tests.

 xfs/053         (data exposure)
 xfs/137         (data vs filesize)
 xfs/138         (data vs filesize vs truncate)
 xfs/139         (data vs filesize vs partial truncate)
 xfs/140         (data vs filesize vs extending truncate)
 xfs/179         (data vs filesize w/ fsync)
 xfs/180         (data vs filesize w/ sync)
 xfs/182         (data vs filesize w/ recovery)
 xfs/200         (recovery vs ro-block device)
 xfs/306         (fsstress vs recovery)

 xfs/085
 xfs/086
 xfs/087

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fsx: check for filesystem support of FALLOCATE_FL_KEEP_SIZE

The NFS implementation of fallocate() does not support passing the
KEEP_SIZE flag by itself, causing tests to randomly fail.

Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: add regression test for remount with thread_pool resized

Regression test for a btrfs issue of resizing 'thread_pool' when
remount the fs.

This regression was introduced by the following linux kernel commit:
    btrfs: Added btrfs_workqueue_struct implemented ordered
    execution based on kernel workqueue
    08a9ff3264181986d1d692a4e6fce3669700c9f8
And it was fixed by the following linux kernel commit:
    btrfs: fix crash in remount(thread_pool=) case
    800ee2247f483b6d05ed47ef3bbc90b56451746c

Signed-off-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4/304: ignore EINVAL and ENODATA error

ext4/304 is also ext4 defragmentation stress test, which creates several
threads to perform defragmentation using 'inplace' mode, but there is a
possible race that the donor file has been truncated by thread_A, while
thread_B starts to call ioctl(EXT4_IOC_MOVE_EXT), then we may get a
EINVAL or ENODATA error.

Please see: http://www.spinics.net/lists/linux-ext4/msg46900.html for
detailed information.

Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: helper to print raw byte output from qgroup show

Newer versions of btrfs-progs change the default output of 'qgroup
show', we have to check what version is running and use the right option
if needed.

Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: xfs_repair secondary sb verification regression test

The secondary superblock verification in xfs_repair was subject to a bug
that unnecessarily leads to a brute force superblock scan if the last
superblock in the fs happens to be corrupt. Normally, xfs_repair handles
one-off superblock corruption gracefully using a heuristic that finds
the most consistent superblock content across the set of secondary
superblocks.

Create a regression test for xfs_repair that corrupts the last
superblock in the fs. Verify the superblock is updated from the
previously verified sb content and a brute force scan is not initiated.
In the event of failure, detect that a brute force scan has started and
abort the repair in order to fail the test quickly.

To support the test, extend the xfs_repair filter to handle corrupted
superblock repair output and provide generic test output for arbitrary
AG counts.

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

shared/032: handle mkfs.* in either /sbin or /usr/sbin

mkfs executables may live in either /sbin or /usr/sbin, and
the current regexp in this test only catches the former,
and so the test won't run properly with the latter.

Fix this by filtering out whatever was found as
${MKFS_PROG}, rather than a hard-coded /sbin/mkfs path.

Because the list was generated by using a wildcard
with ${MKFS_PROG}.* this will always be the correct filter.

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

xfs: add test for XFS_IOC_FSSETXATTR behaviour

Adds a new test that checks for correct behaviour of
XFS_IOC_FSSETXATTR for directories: extent sizes should always be
settable on a directory, even if the directory already has allocated
extents.

Signed-off-by: Iustin Pop <iustin@k1024.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4/30[23]: ignore EBUSY error

xfstests ext4/302, ext4/303 are ext4 defragmentation stress test,
which will ioctl(EXT4_IOC_MOVE_EXT), so EBUSY is expected to happen,
for example, when page's corresponding buffer_head's state is BH_Dirty.

Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Acked-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: add _disable_dmesg_check function

Introduce _disable_dmesg_check function, which can be called by tests
that generate WARNINGs etc. on purpose, so the tests won't fail
_dmesg_check.

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

check: check dmesg log after each test

Check kernel BUG, WARNING etc. in dmesg log after each test and fail the
test if something is found. dmesg log can be found at result dir.

This check now depends on the logging of running tests in dmesg, so this
check can be done without clearing dmesg buffer nor dumping all dmesg to
a file, which can potentially eat all free space on testing host.

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

check: log running test to dmesg

We already log the running test to system logs via "logger"
but viro pointed out that we can use /dev/kmsg to insert it
into dmesg as well.  When looking at the serial console that
could be pretty useful.

Thanks to viro for the test -w suggestion too.

[Eryu Guan adds timestamp to dmesg too]

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

btrfs/017: support all possible page sizes

Currently this test fails on 2 situations:

1) The scratch device supports trim/discard. In this case any modern
   version of mkfs.btrfs outputs a message (to stderr) informing that
   a trim is performed, which the golden output doesn't expect:

   btrfs/017  - output mismatch (see /git/xfstests/results//btrfs/017.out.bad)
       --- tests/btrfs/017.out 2015-01-06 11:14:22.730143144 +0000
       +++ /git/xfstests/results//btrfs/017.out.bad 2015-01-14 22:33:01.582195719 +0000
       @@ -1,4 +1,5 @@
        QA output created by 017
       +Performing full device TRIM (100.00GiB) ...
        wrote 8192/8192 bytes at offset 0
          XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
        4096 4096
        ...
        (Run 'diff -u tests/btrfs/017.out /git/xfstests/results//btrfs/017.out.bad'  to see the entire diff)

    So like others tests do, just redirect mkfs' standard error.

2) On platforms with a page size greater than 4Kb. At the moment btrfs
   doesn't support a node/leaf size smaller than the page size, but it
   supports a larger one. So use the max supported node size (64Kb) so
   that the test runs on any platform currently supported by Linux.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic: test fsync on inode with many hard links differently

This test is motivated by an fsync issue discovered in btrfs.
The steps to trigger the issue were:

1) remove an hard link from an inode with a large number of hard links;
2) add a new hard link;
3) add another hard link with the same name as the one removed in step 1;
4) fsync the inode.

These steps made the btrfs fsync log replay fail (with the -EOVERFLOW
error), making the filesystem unmountable, requiring the use of
btrfs-zero-log (it wipes the fsync log) in order to make the filesystem
mountable again (but losing some data/metadata).

The btrfs issue was fixed by the following linux kernel patches:

  Btrfs: fix fsync when extend references are added to an inode
  Btrfs: fix fsync log replay for inodes with a mix of regular refs and extrefs

This issue was present in btrfs since the extrefs (extend references)
feature was added (2012).

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

generic: test fsync on inode with many hard links

This test is motivated by an fsync issue discovered in btrfs.
The issue in btrfs was that adding a new hard link to an inode that
already had a large number of hardlinks and fsync the inode, would
make the fsync log replay code update the inode with a wrong link count
(smaller than the correct value). This resulted later in dangling
directory index entries, after removing most of the hard links
(correct_value - wrong_value), that were visible to user space but it
was impossible to delete them or do any other operation on them (since
they pointed to an inode that didn't exist anymore, resulting in -ESTALE
errors).

The btrfs issue was fixed by the following linux kernel patch:

   Btrfs: fix fsync when extend references are added to an inode

This issue was present in btrfs since the extrefs (extend references)
feature was added (2012).

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

generic: test fsync after unlink

This test is motivated by an fsync issue discovered in btrfs.
The issue was that after fsyncing an inode that got its link count
decremented, and the new link count is greater than zero, after the
fsync log replay the inode's parent directory metadata became
inconsistent - it had a wrong i_size and dangling index entries which
prevented the directory from ever being removed (rmdir always failed
with -ENOTEMPTY, even if the directory had no more child inodes).

The btrfs issue was fixed by the following linux kernel patch:

    Btrfs: fix directory inconsistency after fsync log replay

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 function _require_batched_discard()

Commit 01d42b7efe3fcb9169befda3072c41d25a87c920 broke the check
for the success status of running fstrim. The [ ] bracets should
have been killed. This made several tests being skipped even when
the test/scratch devices support trim/discard.

For reference:

$ [ fstrim /mnt/ ] || echo foobar
bash: [: fstrim: unary operator expected
foobar

$ fstrim /mnt/ || echo foobar
$ echo $?
0

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

xfstests: f2fs support

This patch adds to support f2fs file system.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs/111: fix cp of missing file

After installing the test suite, src directory only contains binary
programs in the final building directory. Here executing "cp src/itrash.c
$SCRATCH_MNT/${I}" will output "cp: cannot stat 'src/itrash.c': No
such file or directory" error message. Fix it.

Signed-off-by: Xing Gu <gux.fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

Reiser4 initial implementation

Initial xfstests implementation for Reiser4 filesystem.

Signed-off-by: Dushan Tcholich <dusanc@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4/004: limit the amount of data written so test runs faster

Previously this test was taking 6-7 minutes, and writing half a
gigabyte of data in the dump/restore test directory.  Change this to
be about 60 megs, and to take ~20 seconds.

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

check: treat _check_{test,scratch}_fs failures as test failures

Currently if _check_test_fs and/or _check_scratch_fs find corruption,
the test itself is still reported as pass, like

[root@hp-dl388eg8-01 xfstests]# ./check xfs/071 xfs/072
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 hp-dl388eg8-01 3.18.0-rc7+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/sda6
MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/sda6 /mnt/testarea/scratch

xfs/071  2s
_check_xfs_filesystem: filesystem on /dev/sda6 is inconsistent (r) (see /root/xfstests/results//xfs/071.full)
xfs/072  1s
Ran: xfs/071 xfs/072
Passed all 2 tests

[root@hp-dl388eg8-01 xfstests]# echo $?
0

Usually it's not a problem, but it does confuse scripts that depend on
return value of check. Update check to treat _check_{test,scratch}_fs
failures as test failures too, new test output is like

[root@hp-dl388eg8-01 xfstests]# ./check xfs/071 xfs/072
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 hp-dl388eg8-01 3.18.0-rc7+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/sda6
MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/sda6 /mnt/testarea/scratch

xfs/071 2s ... 2s
_check_xfs_filesystem: filesystem on /dev/sda6 is inconsistent (r) (see /root/xfstests/results//xfs/071.full)
xfs/072 1s ... 1s
Ran: xfs/071 xfs/072
Failures: xfs/071
Failed 1 of 2 tests

[root@hp-dl388eg8-01 xfstests]# echo $?
1

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

common: return failure if _check_xxx_filesystem find corruption

So the callers could know if these functions find corruptions by the
return value.

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

common: exit only if tests find corruption

If _check_xxx_filesystem called by tests when corruption found
they exit, but we don't want the calls from the test harness itself to
exit when corruption is found.

_check_xfs_filesystem already behaves correctly, make
_check_generic_filesystem and _check_btrfs_filesystem follow the same
behavior.

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

btrfs: add test case for qgroup account on shared extents

This is a regression test of
'commit fcebe4562dec ("Btrfs: rework qgroup accounting")',
it's used to verify that removing shared extents can end up incorrect
qgroup accounting.

It can produce qgroup related warnings.

The fix is https://patchwork.kernel.org/patch/5499981/
"Btrfs: fix a warning of qgroup account on shared extents"

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

Check O_DIRECT support before testing direct I/O

Some filesystems do not support O_DIRECT.  Check whether TEST_DIR supports
it by running xfs_io with -d flag.

Signed-off-by: Junho Ryu <jayr@google.com>
Signed-off-by: Dushan Tcholich <dusanc@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

generic/038: require fallocate support

Add test for fallocate(2) support

Signed-off-by: Dushan Tcholich <dusanc@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: unify _require_batched_discard

To check for FITRIM tests used  _require_fstrim() and
_test_batched_discard() but as _test_batched_discard() already
includes _test_fstrim() unify FSTRIM check throughout xfstests with
_require_batched_discard().

Signed-off-by: Dushan Tcholich <dusanc@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

ext4/308: require fallocate support

These tests use the falloc command in xfs_io, and there are some file
systems (ext3) or file system configurations (ext4 in ext3
compatibility mode) which do not support fallocate.  So add the
explicit requirement to avoid false test failures.

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

btrfs: add regression test for clone ioctl

Regression test for a btrfs clone ioctl issue where races between
a clone operation and concurrent target file reads would result in
leaving stale data in the page cache. After the clone operation
finished, reading from the clone target file would return the old
and no longer valid data. This affected only buffered reads (i.e.
didn't affect direct IO reads).

This issue was fixed by the following linux kernel patch:

    Btrfs: ensure readers see new data after a clone operation
    (commit c125b8bff1d9f6c8c91ce4eb8bd5616058c7d510)

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fstests: btrfs, add test for snapshoting after file write + truncate

Regression test for a btrfs issue where if right after the snapshot
creation ioctl started, a file write followed by a file truncate
happened, with both operations increasing the file's size, the created
snapshot would capture an inconsistent state of the file system tree.
That state reflected the file truncation but it didn't reflect the
write operation, and left a gap between two file extent items (and
that gap corresponded to the total or a partial area of the write
operation's range).

This issue was fixed by the following linux kernel patch:

    Btrfs: fix snapshot inconsistency after a file write followed by truncate

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: use mke2fs -F instead of piping in yes

It's possible based on a race conditions (and possibly the version of
coreutils which supplies /usr/bin/yes) that commands of the form:

yes | $MKFS_PROG ...

will end up causing the following failure:

shared/298 16s ... [23:49:03] [23:49:19] - output mismatch (see /results/results-4k/shared/298.out.bad)
    --- tests/shared/298.out 2014-10-31 10:13:04.000000000 -0400
    +++ /results/results-4k/shared/298.out.bad 2014-11-29 23:49:19.118138099 -0500
    @@ -1,4 +1,6 @@
     QA output created by 298
    +yes: standard output: Broken pipe
    +yes: write error
     Generating garbage on loop...done.
     Running fstrim...done.
     Detecting interesting holes in image...done.
    ...
    (Run 'diff -u tests/shared/298.out /results/results-4k/shared/298.out.bad'  to see the entire diff)

Using mke2fs's -F option instad of "yes | $MKFS_PROG" fixes this issue.

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

generic/299: make sure fio really exits

Fix two problems in generic/299

1. Remove $seqres.full before test, otherwise the file is growing all
the time.

2. Make sure fio really exits, otherwise fio would block umount. $pid is
the pid of function run_check not fio, sometimes fio is still there when
$pid is dead and blocking umount.

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

cifs: add missing Makefile

This fixes the make install target, which traverses all tests/*
subdirectories.

Reported-by: David Drysdale <drysdale@google.com>
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: add groups for btrfs tests

Some new btrfs groups have been added in the btrfs stress patchset, add
other tests to proper groups too.

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

ext4: the _require checks for bigalloc need a larger fs size

_require_ext4_bigalloc and _require_ext4_mkfs_bigalloc create a
200k fs. DAX (as XIP before it) relies on a fs block size ==
system page size; ie 4k for us.  With a 200k fs size limit,
mkfs refuses to create a filesystem with a 4k block size, so
the check fails, but for a bogus reason.
Increasing the fs size to 512m allows mkfs to create a filesystem
with 4k block size, so the test passes.

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

common: fix comment about _require_test

_require_test will mount test dev if not mounted, fix the comment to
reflect that.

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

btrfs/017: remove duplicate test

btrfs/017 is same as btrfs/015, remove it.

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

fstests: change mode of test files to 0755

Performed by

find tests -perm 644 -name [0-9][0-9][0-9] -exec chmod 755 {} \;

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

xfs/071: remove xfs/071.out from git

xfs/071.out is supposed to linked to the right out file at run time.

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

cifs: add server-side copy sanity test

This test uses the cloner binary to issue CIFS_IOC_COPYCHUNK_FILE
server-side copy requests.

Signed-off-by: David Disseldorp <ddiss@suse.de>
Acked-by: Steve French <smfrench@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

common: rename _require_btrfs_cloner to _require_cloner

src/cloner.c is no longer Btrfs specific, so use a generic name.

Signed-off-by: David Disseldorp <ddiss@suse.de>
Acked-by: Steve French <smfrench@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

btrfs: add test to stress chunk allocation/removal and fstrim

Stress btrfs' block group allocation and deallocation while running
fstrim in parallel. Part of the goal is also to get data block groups
deallocated so that new metadata block groups, using the same physical
device space ranges, get allocated while fstrim is running. This caused
several issues ranging from invalid memory accesses, kernel crashes,
metadata or data corruption, free space cache inconsistencies, free
space leaks and memory leaks.

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

ext4: add dump/restore test

This test case will first use fsstress to fill a file system, then
dump it to standard output and restore it from standard input, finally
check that the original contents and the new contents generated by
restore tool will be same.

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