From Goldwyn Rodrigues <rgoldwyn@suse.de>:
"From earlier discussions, In between errors of a direct I/O cannot
be handled correctly and may need a lot of tracking that it is not
worth performing.
It would be better to drop this test case and add in the documentation
that a direct I/O error could mean that the write() may or may not have
occurred and underlying data may be inconsistent."
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Currently the only test in group 'thin' is 347. On some recent
kernels tests that use dm-thin causing kernel crashes, so it's useful
to be able to be exclude all tests that use dm-thin.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This tests the online label ioctl that btrfs has, which has been
recently proposed for XFS.
To run, it requires an updated xfs_io with the label command and a
filesystem that supports it
A slight change here to _require_xfs_io_command as well, so that
tests which simply fail with "Inappropriate ioctl" can be caught in
the common case.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With ext4, this leads to freeze proection bypass WARN_ON in
ext4_journal_check_start.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
ext4 had a bug for files with indirect extents where it wrongly
reported a size of a hole in some cases and thus SEEK_DATA
implementation could skip some data in a file. Test for that. The
problem is fixed by patch "ext4: Fix hole length detection in
ext4_ind_map_blocks()".
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that xattrs are not lost after calling fsync multiple times
with a filesystem commit in between the fsync calls.
This test is motivated by a bug found in btrfs which is fixed by a
patch for the linux kernel titled:
Btrfs: fix xattr loss after power failure
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Btrfs has a bug where we can prematurely ENOSPC if we have lots of
orphaned files, i.e., deleted files which are still open. Add a test
which repeatedly creates and deletes a file while keeping all of the
file descriptors open. This should succeed but doesn't on Btrfs
without the fix.
[Eryu: use multi_open_unlink command to keep files open & unlinked
instead of shell scripts]
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This adds a regression test for the following kernel patch:
b4678df184b3 ("errseq: Always report a writeback error once")
This is motivated by some rather odd behavior done by the PostgreSQL
project. The main database writers will offload the fsync calls to a
separate process, which can open files after a writeback error has
already occurred.
This used to work with older kernels that reported the error to only
one fd, but with the errseq_t changes we lost the ability to see
errors that occurred before the open. The above patch restores that
behavior.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There are a bunch of tests that are run by the auto group that are
marked dangerous. This was done because the test exercised a crash
or other fatal error that has since been fixed. Remove the dangerous
tag from the auto tests that pass on a 4.17-rc3 kernel as they are
not dangerous anymore.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Kanda Motohiro reported that expanding a tiny xattr into a large
xattr fails on XFS because we remove the tiny xattr from a shortform
fork and then try to re-add it after converting the fork to extents
format having not removed the ATTR_REPLACE flag. This fails because
the attr is no longer present, causing a fs shutdown.
[Eryu: introduce function "fail" and use it where appropriate]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199119
Reported-by: kanda.motohiro@gmail.com
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test how the "insert range" fallocate operation interacts with the
maximum file size (s_maxbytes).
- Shift extents past the max file size (exposes an ext4 bug).
- Increase i_size past the max file size (exposes an xfs bug).
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
POSIX requires that record locks are preserved across an execve(2).
But currently the locks are released if process is multithreaded at
the time that execve is called.
As Jeff Layton wrote in his patch:
"
In that case, we'll end up unsharing the files_struct but the locks
will still have their fl_owner set to the address of the old one.
Eventually, when the other threads die and the last reference to the
old files_struct is put, any POSIX locks get torn down since it
looks like a close occurred on them.
The result is that all of your open files will be intact with none
of the locks you held before execve.
"
Add a new regression test for this particular case.
[Eryu: rewrite commit log and test description]
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that fsync operations preserve extents allocated with
fallocate(2) that are placed beyond a file's size.
This test is motivated by a bug found in btrfs where unwritten
extents beyond the inode's i_size were not preserved after a fsync
and power failure. The btrfs bug is fixed by the following patch for
the linux kernel:
"Btrfs: fix loss of prealloc extents past i_size after fsync log replay"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Basic test case which triggers fsstress with dm-log-writes, and then
check the fs after each FUA writes.
With needed infrastructure and special handlers for journal based fs.
[Eryu: cap $nr_cpu to 8 to avoid wasting time on hosts with many cpus]
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The regression is introduced to btrfs in linux v4.4 and it refuses to
create new files after log replay by returning -EEXIST.
Although the problem is on btrfs only, there is no btrfs stuff in terms
of test, so this makes it generic.
The kernel fix is
Btrfs: fix unexpected -EEXIST when creating new inode
[Eryu: add _require_metadata_journaling rule and 'log' 'metadata' group]
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we have a file with two hard links in the same parent
directory, then remove of the links, create a new file in the same
parent directory and with the name of the link removed, fsync the new
file and have a power loss, mounting the filesystem succeeds.
This test is motivated by a bug found in btrfs, which is fixed by
the linux kernel patch titled:
"Btrfs: fix log replay failure after unlink and link combination"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that when a fsync journal/log exists, if we rename a special file
(fifo, symbolic link or device), create a hard link for it with its old
name and then commit the journal/log, if a power loss happens the
filesystem will not fail to replay the journal/log when it is mounted
the next time.
This test is motivated by a bug found in btrfs, which is fixed by the
following patch for the linux kernel:
"Btrfs: fix log replay failure after linking special file and fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/472 is for changes that are not upstream and seem dead in
the water at the moment, so remove this test from the auto and quick
groups until it's been resolved upstream and the changes merged.
generic/473 really doesn't seme useful. FIEMAP is a debugging
interface, xfs_io is a debugging tool and so trying to make every
filesytem report exactly the same thing for a ranged query just
strikes me as the wrong thing to be doing. This fails on XFS, and
there's no apparent resolution to that in sight, so remove the test
from the auto and quick, too.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test OFD locks. Use fcntl F_OFD_SETLK/F_OFD_GETLK, to verify we are
being given correct advices through getlk by kernel.
The basic idea is one setlk routine setting locks via fcntl *_SETLK,
followed by operations like clone, dup then close fd; another
routine getlk getting locks via fcntl *_GETLK.
Firstly in setlk routine process P0, place a lock L0 on an opened
testfile, then do clone or dup and close relative fd.
In getlk process P2, do fcntl *_GETLK with lock L1 after get
notified by setlk routine.
In the end, getlk routine check the returned struct flock.l_type to
see if the lock mechanism works fine.
Test combainations of:
- shared or exclusive lock
- these locks are conflicting or not
- one OFD lock and one POSIX lock
- that open testfile RDONLY or RDWR
- clone with CLONE_FILES or not
- dup and close newfd
[eguan: made some minor non-functional changes]
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
open_by_handle can now store and load file handles from a file:
usage:
open_by_handle -p -o <handles_file> <test_dir> [N]
open_by_handle -p -i <handles_file> <test_dir> [N]
Add a new generic/exportfs test to use these new options to test
decoding file handles after cycle mount and after directory renames.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Let a lot of writes soak in with multithreaded fsstress to look for
bugs and other problems.
[eguan: remove '-v' option of fsstress and remove 'clone' group]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test log recovery with repeated (simulated) disk failures. We kick
off fsstress on the scratch fs, then switch out the underlying
device with dm-error to see what happens when the disk goes down.
Having taken down the fs in this manner, remount it and repeat.
This test is a Good Enough (tm) simulation of our internal multipath
failure testing efforts.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Inspired by syncfs bug of overlayfs which does not sync dirtyinodes
in underlying filesystem.
Run syncfs and shutdown filesystem(or underlying filesystem of
overlayfs) to check syncfs result.
Signed-off-by: Chengguang Xu <cgxu519@icloud.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Other generic tests that test dedupe all have 'dedupe' group except
generic/304. Add 304 to dedupe group too.
[eguan: add commit log]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Fiemap gained support for passing in optional offset len which
denote the range requested, so this patch adds testcases for this
functionality. Aditionally, a special "ranged" argument is added to
the require_xfs_io_command which checks for the presence of fiemap
range support.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Theodore Ts'o
Eric Sandeen
Amir Goldstein
Jan Kara
Filipe Manana
Omar Sandoval
Jeff Layton
Dave Chinner
Darrick J. Wong
Eric Biggers
Xiong Zhou
Qu Wenruo
Liu Bo
Chengguang Xu
Luis R. Rodriguez
Nikolay Borisov