Move the cp --reflink tests from btrfs/ to generic/ since xfs now
supports that ioctl.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Check if setting the file access and modification times to the current time
and to a specific timestamp is allowed when expected.
In generic/126, remove a left-over temporary file.
Signed-off-by: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test exercises the problem with unwritten and delayed extents
in ext4 extent status tree where we might in some cases lose a block
worth of data. Even though this was a ext4 specific problem the
reproducer can be easily run on any file system so let's do that just
in case.
This test exercises the problem fixed in kernel with commit
"ext4: Fix data corruption caused by unwritten and delayed extents"
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Exercise fs freeze/unfreeze and mount/umount race, which could lead to
use-after-free oops.
This commit fixed the issue:
1494583 fix get_active_super()/umount() race
This test case is based on a script from Monakhov Dmitriy.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Kernel commit
aae8a97 fs: Don't allow to create hardlink for deleted file
disabled hardlink to unlinked file.
Test the race between link and unlink, which could end up adding link
count to an unlinked file and leading to fs corruption on xfs.
Test case was originally written by Eric Sandeen.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
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>
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 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>
Darrick J. Wong
Eric Sandeen
Eryu Guan
Jan Kara
Filipe Manana
Brian Foster
Wang Yanfeng
Lukas Czerner
Josef Bacik
Andrew Price
Andreas Gruenbacher
Omer Zilberberg