Remount ro should not turn qouta off unconditionally, even remount ro
failed, also kernel should not oops on the next succeeded remount ro.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that btrfs' transaction abortion does not corrupt a filesystem
mounted with -o discard nor allows a subsequent fstrim to corrupt the
filesystem (regardless of being mounted with or without -o discard).
This issue was fixed by the following linux kernel patch:
Btrfs: fix fs corruption on transaction abort if device supports discard
(commit 678886bdc6378c1cbd5072da2c5a3035000214e3)
Without the corresponding btrfs fix the fs becomes unmountable and fails
like this:
$ ./check btrfs/089
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian3 3.19.0-btrfs-next-7+
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/089 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/089.out.bad)
--- tests/btrfs/089.out 2015-04-03 19:29:42.969594083 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/089.out.bad 2015-04-03 19:42:37.419181019 +0100
@@ -3,7 +3,10 @@
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
wrote 1048576/1048576 bytes at offset 524288
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+mount: wrong fs type, bad option, bad superblock on /dev/sdc,
+ missing codepage or helper program, or other error
+ In some cases useful info is found in syslog - try
+ dmesg | tail or so
...
(Run 'diff -u tests/btrfs/089.out /home/fdmanana/git/hub/xfstests/results//btrfs/089.out.bad' to see the entire diff)
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent (see /home/fdmanana/git/hub/xfstests/results//btrfs/089.full)
Ran: btrfs/089
Failures: btrfs/089
Failed 1 of 1 tests
$ cat /home/fdmanana/git/hub/xfstests/results//btrfs/089.full
Performing full device TRIM (100.00GiB) ...
touch: cannot touch '/home/fdmanana/btrfs-tests/scratch_1/abc': Read-only file system
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
Check tree block failed, want=29589504, have=0
read block failed check_tree_block
Couldn't read tree root
Couldn't open file system
(...)
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
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>
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>
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>
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>
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>
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>
Eryu Guan
Filipe Manana
Dave Chinner
Omer Zilberberg
Eric Sandeen
Jeff Mahoney
Xiaoguang Wang
Zhao Lei