Some tests that use dmflakey to test filesystem consistency after a power
failure are in the 'log' group while others are not. So fix the
incosistency and put them all under the 'log' group.
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 ctime gets updated and suid is cleared when we reflink.
Ensure we can't reflink about RLIMIT_FSIZE. Ensure that we can't
expose stale preallocation block data when reflinking above EOF.
Make sure dedupe actually catches a single different byte.
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 have a very small file, with a size smaller than the
block size, then fallocate a very small range within the block size
but past the file's current size, fsync the file and then power
fail, after mounting the filesystem all the file data is there and
the file size is correct.
This test is motivated by a failure in btrfs where it triggered an
assertion when using the no-holes feature, that is, when running
with MKFS_OPTIONS="-O no-holes". The btrfs issue is fixed by a patch
for the linux kernel titled:
"Btrfs: fix assertion on fsync of regular file when using no-holes
feature"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add Brian Foster's alternate reproducer code for the mread-after-eof
problem so that we increase the chances that either this or generic/499
will catch the problem.
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 move a file from a directory B to a directory A, replace
directory B with directory A, fsync the file and then power fail, after
mounting the filesystem the file has a single parent, named B and there
is no longer any directory with the name A.
This test is motivated by a bug found in btrfs which is fixed by a patch
for the linux kernel titled:
"Btrfs: fix wrong dentries after fsync of file that got its parent
replaced"
This test passes on ext4, xfs and patched btrfs but it hangs on f2fs (the
fsck.f2fs process seems stuck).
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 fsync a tmpfile, without adding a hard link to it, and
then power fail, we will be able to mount the filesystem without
triggering any crashes, warnings or corruptions.
This test is motivated by an issue in btrfs where this scenario triggered
a warning (without any side effects). The following linux kernel patch
fixes the issue in btrfs:
"Btrfs: fix warning when replaying log after fsync of a tmpfile"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
creation time being persisted, so even after sudden power-cut, during
mount, we should recover i_crtime_{,nsec} fields correctly, in order
to not loss those meta info.
So adding this testcase to check whether generic filesystem can
guarantee that.
Note that, it needs inode creation time support on specified filesystem.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
i_flags being persisted, so even after sudden power-cut, during
mount, we should recover i_flags fields correctly, in order to not
loss those meta info.
So adding this testcase to check whether generic filesystem can
guarantee that.
We only check below attribute modification which most filesystem
supports:
- no atime updates (A)
- secure deletion (s)
- synchronous updates (S)
- undeletable (u)
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
project id being persisted, so even after sudden power-cut, during
mount, we should recover project_id fields correctly, in order to
not loss those meta info.
So adding this testcase to check whether generic filesystem can
guarantee that.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
uid/gid being persisted, so even after sudden power-cut, durign
mount, we should recover uid/gid fields correctly, in order to not
loss those meta info.
So adding this testcase to check whether generic filesystem can
guarantee that.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Regression test case for kernel patchset:
fs/lock: show locks info owned by dead/invisible processes
Open new fd by exec shell built-in, then require exclusive lock
by flock(1) command. Checking /proc/locks for the lock info.
This patchset post by Konstantin Khorenko <khorenko@virtuozzo.com>
has not been merged v4.18-rc8.
[Eryu: require $FLOCK_PROG and add more comments]
Signed-off-by: Xiong Murphy Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>
Filipe Manana
Darrick J. Wong
Chao Yu
Xiong Murphy Zhou
Ross Zwisler
Zorro Lang
Theodore Ts'o
Omar Sandoval