Test that if we rename a directory, create a new file or directory that
has the old name of our former directory and is a child of the same
parent directory, fsync the new inode, power fail and mount the
filesystem, we see our first directory with the new name and no files
under it were lost.
This test is motivated by an issue found in btrfs which is fixed by the
following patch for the linux kernel:
"Btrfs: fix file loss caused by fsync after rename and new inode"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add test which spawns two threads racing to write to file via mmap and
checks the result. This is mainly interesting to uncover races in DAX
fault handling.
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Brian Boylston <brian.boylston@hpe.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs/006 has no requirements that are specific to XFS, so make it generic
and other filesystems could get some coverage too.
Along with the movement, I also added a test that removes all created
dirs, as that's how the original bug was found.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is a test that performs simple I/O on dm error device, which
returns EIO on all I/O request.
This is motivated by an ext4 bug that crashes kernel on error path when
trying to update atime. Following kernel patch should fix the issue
ext4: fix NULL pointer dereference in ext4_mark_inode_dirty()
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that the filesystem's implementation of the listxattrs system call
lists all the xattrs an inode has.
This test is motivated by a bug found in btrfs, which is fixed by the
following patch for the linux kernel:
"Btrfs: fix listxattrs not listing all xattrs packed in the same item"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Also remove generic/125 from the auto group, and add it to the new
pnfs group. This is to document where this test might be useful; it's
not really going to be useful for most normal on-disk file systems, so
remove it from the auto group.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that if we have a file F1 with two links, one in a directory A and
the other in directory B, if we remove the link in directory B, move some
other file F2 from directory B into directory C, fsync inode F1, power
fail and remount the filesystem, file F2 exists and is located only in
directory C.
This is motivated by a bug found in btrfs, which is fixed by the patch
(for the linux kernel) titled:
"Btrfs: fix file loss on log replay after renaming a file and fsync"
Tested against ext3, ext4, 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 move one file between directories, fsync the parent
directory of the old directory, power fail and remount the filesystem,
the file is not lost and it's located at the destination directory.
This is motivated by a bug found in btrfs, which is fixed by the patch
(for the linux kernel) titled:
"Btrfs: fix file loss on log replay after renaming a file and fsync"
Tested against ext3, ext4, 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>
Since 'quick' tests are supposed to run in < 15s, kick out the ones
that can't finish that soon even on fast storage.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Set up an impossibly small filesystem and try to reflink and rewrite a
file on it to see what happens when we ENOSPC. Basically
generic/16[67] but with a constrained fs size.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Ensure that we can pass absurdly enormous offsets and lengths to
reflink/dedupe and it'll survive.
v2: Ask for dedupe in the dedupe test.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
[hch@lst.de: call _require_test_dedupe]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Perform copy-on-writes at random offsets to stress the CoW allocation
system. Assess the effectiveness of the extent size hint at
combatting fragmentation via unshare, a rewrite, and no-op after the
random writes.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Update the existing stress tests to ensure that we can handle
reflinking the same block a million times, and that we can handle
reflinking million different extents. Add a couple of tests to ensure
that we can ^C and SIGKILL our way out of long-running reflinks.
v2: Don't run the signal tests on NFS, as we cannot interrupt NFS
clone operations.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
[hch@lst.de: don't run on NFS]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Ensure that CoW operations against shared blocks in the source file
work correctly.
v2: remove filefrag dependencies
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Test various scenarios (with dm-flakey) where we simulate write
failures during CoW, to see if the FS can get through it without
blowing up or corrupting data. Plumb in a FS-generic method to
sort out repairing filesystems after they get hit by IO errors.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Ensure that we correctly handle a CoW operation immediately followed
by a truncate, falloc, fpunch, fzero, fcollapse, and finsert operation
in the middle of the CoW'd region before any flush can occur.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Check that we don't expose old disk contents when a directio write to
an unwritten extent fails due to IO errors. This primarily affects
XFS and ext4.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
The new Q_GETNEXTQUOTA quotactl (not yet merged) is designed
to take an ID as input ala Q_GETQUOTA, and return the quota
for the next active ID >= the input ID. This lets us quickly
iterate over all existing quotas by leveraging the kernel's
knowledge of which quotas are allocated and active.
The test contains a new helper binary, test-nextquota, which
tests both the "vfs" and "xfs" versions of the quotactl.
It accepts an ID, and outputs the returned ID, ihard, and
isoft values for that quota. It doesn't return block information
simply because that can vary depending on fs, block size, etc,
and we want something very consistent as output, for verifiation.
The test harness sets quotas for 100 random IDs, remounts,
and uses these quotactls to iterate over all the IDs we set,
using the test binary, making sure we get back what we expect.
Not the prettiest thing, but it works!
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test what happens when we send largeish buffers to CoW all at once.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test CoW operations when blocksize < pagesize and the only reflink
block is in the middle of the page.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
These tests examine the behavior of advanced and tricky copy on write
situations.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add more tests for unaligned copy-on-write things, and explicitly
test the ability to pass "len == 0" to mean reflink/dedupe all
the way to the end of the file".
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Filipe Manana
Jan Kara
Eryu Guan
Theodore Ts'o
Darrick J. Wong
Eric Sandeen