This adds a regression test for the following series:
[PATCH v4 0/2] ext4: fix DAX dma vs truncate/hole-punch
https://lists.01.org/pipermail/linux-nvdimm/2018-July/016842.html
which adds synchronization between DAX DMA in ext4 and truncate/hole-punch.
The intention of the test is to test those specific changes, but it runs
fine both with XFS and without DAX so I've put it in the generic tests
instead of ext4 and not restricted it to only DAX configurations.
When run with v4.18-rc6 + DAX + ext4, this test will hit the following
WARN_ON_ONCE() in dax_disassociate_entry():
WARN_ON_ONCE(trunc && page_ref_count(page) > 1);
If you change this to a WARN_ON() instead, you can see that each of the
four paths being exercised in this test hits that condition many times in
the one second that the subtest is being run.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we have a file with 2 (or more) hard links in the same
parent directory, rename of the hard links, rename one of the other
hard links to the old name of the hard link we renamed before,
create a new file in the same parent directory with the old name of
second hard link we renamed, fsync fsync this new file and power
fail, we will be able to mount again the filesystem and the new file
and all hard links exist.
This test is motivated by a bug found in btrfs, where mounting the
filesystem after the power failure resulted in failure with an errno
value of EEXIST, which is fixed by a patch for the linux kernel
titled:
"Btrfs: fix mount failure after fsync due to hard link recreation"
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 if we do a buffered write to a file, fsync it, clone a
range from another file into our file that overlaps the previously
written range, fsync the file again and then power fail, after we
mount again the filesystem, no file data was lost or corrupted.
This test is motivated by a bug found in btrfs, which is fixed by a
patch for the linux kernel titled:
"Btrfs: fix file data corruption after cloning a range 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>
If a user constructs a test that loops repeatedly over below steps
on dm-thin, block allocation can fail due to discards not having
completed yet (Fixed by a685557 dm thin: handle running out of data
space vs concurrent discard):
1) fill thin device via filesystem file
2) remove file
3) fstrim
And this maybe cause a deadlock (fast device likes ramdisk can help
a lot) when racing a fstrim with a filesystem (XFS) shutdown. (Fixed
by 8c81dd46ef3c Force log to disk before reading the AGF during a
fstrim)
This case can reproduce both two bugs if they're not fixed. If only
the dm-thin bug is fixed, then the test will pass. If only the fs
bug is fixed, then the test will fail. If both of bugs aren't fixed,
the test will hang.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Certain sequences of generic/127 invocations complain about being
able to mread nonzero contents past eof. Replicate that here as a
regression test.
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 that if we create a new hard link for a file which was
previously fsync'ed, fsync a parent directory of the new hard link
and power fail, the parent directory exists after mounting the
filesystem again. The parent directory must be a new directory, not
yet persisted.
This test is motivated by a bug found in btrfs, where the fsync'ed
parent directory was lost after a power failure. The bug in btrfs is
fixed by a patch for the linux kernel titled:
"Btrfs: sync log after logging new name"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Update the group files to annotate those tests which have a
_require_xfs_io_command for punch, collapse, insert, and zero. This
makes it easier to exclude tests that use one of these fallocate
commands. Or if you want to specifically test for those fallocate
commands you can do this.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Swap files cannot have holes, and they must at least two pages.
swapon(8) and mkswap(8) have stricter restrictions, so add versions
of those commands without any restrictions.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Similar to generic/356 that makes sure we can't dedupe an active
swapfile.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
I'm going to add a bunch of tests for swap files, so create a group
for them and add the existing tests.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>
Ross Zwisler
Filipe Manana
Zorro Lang
Darrick J. Wong
Theodore Ts'o
Omar Sandoval
Eric Sandeen
Amir Goldstein
Jan Kara
Jeff Layton
Dave Chinner
Eric Biggers
Xiong Zhou