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>
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>
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>
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>
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, 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>
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>
Jeff Mahoney
Eric Sandeen
Filipe Manana
Xiaoguang Wang
Eryu Guan
Dave Chinner
Zhao Lei