This test will test if we can still do the following operations when a
full is full:
- buffered write into unpopulated preallocated extent
- clone the untouched preallocated extent
- fsync
- no data loss if power loss happens after above fsync
Above operations should not fail, as they takes no extra data space.
Xfs passes the test, while btrfs fails at fsync and has data loss.
The fix for btrfs is:
"btrfs: Flush before reflinking any extent to prevent NOCOW write falling
back to CoW without data reservation"
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
It should return error while changing IMMUTABLE_FL and APPEND_FL if the
process has no capability CAP_LINUX_IMMUTABLE.
However, it's not true on overlayfs after kernel version v4.19 since
the process's subjective cred is overridden with ofs->creator_cred
before calling real vfs_ioctl.
The following patch for ovl fix the problem:
"ovl: check the capability before cred overridden"
Add this testcase to cover this bug.
Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add some more clone range tests that missed various "wacky" combinations
of file state. Specifically, we test reflinking into and out of rainbow
ranges (a mix of real, unwritten, hole, delalloc, and shared extents),
and also we test that we can correctly handle double-inode locking no
matter what order of inodes or the filesystem's locking rules.
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>
A simply reproducer from Frank Sorenson:
ftruncate(fd, 65012224)
io_prep_pwrite(iocbs[0], fd, buf[0], 1048576, 63963648);
io_prep_pwrite(iocbs[1], fd, buf[1], 1048576, 65012224);
io_submit(io_ctx, 1, &iocbs[0]);
io_submit(io_ctx, 1, &iocbs[1]);
io_getevents(io_ctx, 2, 2, events, NULL)
help to find an ext4 corruption:
**************** **************** ****************
* page 1 * * page 2 * * page 3 *
**************** **************** ****************
existing 0000000000000000 0000000000000000 0000000000000000
write 1 AAAAAAAAAAAAAA AA
write 2 BBBBBBBBBBBBBB BB
result 00AAAAAAAAAAAAAA 00BBBBBBBBBBBBBB BB00000000000000
desired 00AAAAAAAAAAAAAA AABBBBBBBBBBBBBB BB00000000000000
This issue remind us we might miss unaligned AIO test for long time.
We thought fsx cover this part, but looks like it's not. So this case
trys to cover unaligned direct AIO write test on file with different
initial truncate i_size.
The following patches fix the issue on xfs and ext4.
xfs: serialize unaligned dio writes against all other dio writes
ext4: Fix data corruption caused by unaligned direct AIO
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test makes sure that we can't use stale unrecovered fs metadata to
drive a DISCARD festival on a disk and thereby destroy user data by
accident.
The following patches fixed the bug on ext4, xfs and btrfs
ext4: prohibit fstrim in norecovery mode
xfs: prohibit fstrim in norecovery mode
Btrfs: do not allow trimming when a fs is mounted with the nologreplay option
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
XFS has historically had a stale data exposure window if a crash
occurs after a delalloc->physical extent conversion but before
writeback completes to the associated extent. While this should be a
rare occurrence in production environments due to typical writeback
ordering and such, it is not guaranteed in all cases until data
extents are initialized as unwritten (or otherwise zeroed) before
they are written.
Add a test that performs selective writeback ordering to reproduce
stale data exposure after a crash. Note that this test currently
fails on XFS.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsync, filesystem should guarantee inode metadata including
permission info being persisted, so even after sudden power-cut,
during mount, we should recover i_mode 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: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we truncate a file to reduce its size, rename it and then
fsync it, after a power failure the file has a correct size and name.
This test is motivated by a bug found in btrfs, which is fixed by a
patch for the linux kernel titled:
"Btrfs: fix incorrect file size after shrinking truncate and fsync"
This test currently passes on ext4, xfs, f2fs and patched btrfs.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Split out most of the user.* tests from 097 and move them to a new
test that only tests user.* xattrs.
This makes it possible to use this test on filesystems that can only
provide user.* xattrs such as CIFS.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The sanity test case in those tests (i.e. 13..17)
are all skipped in fs with no falloc support, but the tests
are reported to pass.
For example, from 445.full:
File system supports the default behavior.
File system does not support fallocate.
Allocation size: 4096
17. Test file with unwritten extents, data-hole-data inside page
Test skipped as fs doesn't support unwritten extents.
Explicitly check for falloc support before running those tests
so they would be properly reported as skipped.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create a test (+ helper program) that opens as many unlinked files as it
possibly can on the scratch filesystem, then closes all the files at
once to stress-test unlinked file cleanup. Add an xfs-specific test to
make sure that the fallback code doesn't bitrot.
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>
XFS had a use-after-free bug when xfs_xattr_put_listent runs out of
listxattr buffer space while trying to store the name
"system.posix_acl_access" and then corrupts memory by not checking
the seen_enough state and then trying to shove
"trusted.SGI_ACL_FILE" into the buffer as well.
In order to tickle the bug in a user visible way we must have
already put a name in the buffer, so we take advantage of the fact
that "security.evm" sorts before "system.posix_acl_access" to make
sure this happens.
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>
If statx returns inode creation time (aka btime), check it to make
sure that the filesystem is setting a creation time that's
reasonably close to when it creates a file.
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 after a combination of file renames, linking and creating
a new file with the old name of a renamed file, if we fsync the new
file, after a power failure we are able to mount the filesystem and
all file names correspond to the correct inodes.
This test is motivated by a bug found in btrfs, which is fixed by
applying the following two patches to the linux kernel:
"[PATCH 1/2] Btrfs: fix fsync after succession of renames of different files"
"[PATCH 2/2] Btrfs: fix fsync after succession of renames and unlink/rmdir"
The test passes on ext4, xfs and patched btrfs, however at least in
a 5.0-rc5 linux kernel, it fails on f2fs.
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 after a combination of file renames, linking and creating
a new file with the old name of a renamed file, if we fsync the new
file, after a power failure we are able to mount the filesystem and
all file names correspond to the correct inodes.
This test is motivated by a bug found in btrfs which is fixed by a
patch for the linux kernel titled:
"Btrfs: fix fsync after succession of renames of different files"
The test passes on ext4, xfs and patched btrfs, however at least in
a 5.0-rc5 linux kernel, it fails on f2fs.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a variant of test generic/466 for filesystems that
do not support mkfs_sized
It is needed for testing high-offset reads and writes with overlayfs
over a basefs that supports huge files.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
XFS has a bug where page writeback can end up sending data to the
wrong location due to a stale, cached file mapping. Add a test to
trigger this problem by racing background writeback with a
truncate/rewrite of the final page of the file.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Sandeen recently found a bug in xfs_repair that flagged extended
attribute names containing "/" as corrupt and purged them. There's
nothing in the IRIX or Linux manuals that say anything about slashes not
being allowed (and Linux certainly allows this) so let's make sure this
continues to work.
[Eryu: use $SETFATTR and _getfattr helper]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This patch aims to add more tests to the xfstest suite to check
whether the target file system recovers correctly after a crash.
These test cases are generated by CrashMonkey, a
crash-consistency testing framework built at the SASLab at UT Austin.
This patch batches 37 crash-consistency tests into a xfstest test,
each of which checks the hard link behavior under different scenarios.
This test creates hard-links between files in the same directory or
across directories, while allowing fsync of either the files involved,
their parent directories, or unrelated sibling files. After each sub
test, the metadata of the persisted file is checked for the correct
link count. Additionally, each sub test is followed by fsck to check
for inconsistencies. The tests run on a 256MB file system, and
the working directory is cleaned up after every sub test.
Signed-off-by: Jayashree Mohan <jaya@cs.utexas.edu>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
xfstests doesn't cover FIBMAP test, it cause we brought in a
regression bug fixed by "79b3dbe4adb3 fs: fix iomap_bmap position
calculation".
Although FIBMAP is old, there're still some programs use it, likes
LILO. This case tests if there's physical address overlap returned
by FIBMAP.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that we can not clone a range from a file A into the middle of a file B
when the range includes the last block of file A and file A's size is not
aligned with the filesystem's block size. Allowing such case would lead to
data corruption since the data between EOF and the end of its block is
undefined.
This is motivated by a bug recently found that affects both Btrfs and XFS
and is fixed by the following commits/patches for the linux kernel:
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
b39989009bdb ("xfs: fix data corruption w/ unaligned reflink ranges")
Btrfs: fix data corruption due to cloning of eof block
The VFS patch landed in kernel 4.20-rc1 and the XFS patch landed in 4.19.
The Btrfs fix is very recent and it is not yet in Linus' tree.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Qu Wenruo
Jiufei Xue
Darrick J. Wong
Amir Goldstein
Zorro Lang
Brian Foster
Chao Yu
Filipe Manana
Ronnie Sahlberg
Christoph Hellwig
Jayashree