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>
_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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Filipe Manana
Dave Chinner
Eryu Guan
Jan Tulak
Omer Zilberberg
Eric Sandeen
Jeff Mahoney
Eric Sandeen
Xiaoguang Wang
Zhao Lei