Allocating two bytes at a block boundary with fallocate should allocate
both blocks involved. Test this by writing data to both bytes
afterwards and see whether the on-disk size increases (it should not).
This is a regression test for the kernel patch "xfs: Fix tail rounding
in xfs_alloc_file_space()".
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On file systems with a block size smaller than the page size, hole
punching can leave the pages at the beginning and the end of the
hole partially mapped to disk blocks. Make sure writes to those
pages are handled correctly.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test that checks for xfs drivers that fail to
unlock the inode after changing the group id fails with EDQUOT. It
pairs with "xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails
due to EDQUOT".
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Old kernels do not support cross-device copy_file_range.
This is a regression test for kernel commit:
5dae222a5ff0 vfs: allow copy_file_range to copy across devices
[Amir] Split out cross-device copy_range test to a new test and
_notrun if kernel/filesystem do not support cross-device copy_range.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that copy_file_range will return the correct errors for various
error conditions and boundary constraints.
This is a regression test for kernel commit:
96e6e8f4a68d ("vfs: add missing checks to copy_file_range")
[Amir] Split out cross-device copy_range test and use only test dev.
Split out immutable/swapfile test cases to reduce the requirements to
run the bounds check to minimum and get coverage for more filesystems.
Remove the tests for read past EOF and write after chmod -r,
because we decided to stick with read(2)/write(2) semantics.
Add requirements needed for large size copy tests and fifo test.
Use existing char/block devices for char/block dev tests.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Now that we run the test for all block device based file systems, there
is no reason to keep it out of generic.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we clone a file with some large extents into a file
that has many small extents, when the fs is nearly full, the clone
operation does not fail and produces the correct result.
This is motivated by a bug found in btrfs wich is fixed by the
following patches for the linux kernel:
[PATCH 1/2] Btrfs: factor out extent dropping code from hole punch handler
[PATCH 2/2] Btrfs: fix ENOSPC errors, leading to transaction aborts, when
cloning extents
The test currently passes on xfs.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add _require_scratch_duperemove which validates that the file system
supports duperemove. This allows us to move three tests from shared/
to generic/. This means these tests will automatically adapt when
duperemove supports other file systems. Tests moved are:
shared/008 --> generic/559
shared/009 --> generic/560
shared/010 --> generic/561
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The shared/006 uses _scratch_mkfs_sized to create a limited size
file system, and then creates inodes until it gets ENOSPC, and then
checks to make sure the file system is consistent. It then remounts
the file system, removes all of the files, and makes sure the file
system is consistent afterwards. This test was marked as only being
supported on ext[234] and xfs, and so it was in shared.
Now introduce a new _require_inode_limits() rule to run test on
filesystems that have a fixed inode number, then move the test to
generic.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we fsync a file, evict its inode, unlink it and then fsync
its parent directory, after a power failure the file does not exists.
This is motivated by a bug found in btrfs, which is fixed by the following
patch for the linux kernel:
"Btrfs: fix fsync not persisting dentry deletions due to inode evictions"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This new test implements verification for the per-directory
case-insensitive feature, as supported by the reference
implementation in Ext4.
Signed-off-by: Lakshmipathi.G <lakshmipathi.ganapathi@collabora.co.uk>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
[Rewrite to support feature design]
[Refactor to simplify implementation]
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a flavor of test generic/545 with FS_IOC_FSSETXATTR ioctl
instead of FS_IOC_SETFLAGS ioctl.
Overlayfs gained support for FS_IOC_FSSETXATTR ioctl in v5.2-rc4
with buggy capability check. This change fixed the problem:
ovl: fix wrong flags check in FS_IOC_FS[SG]ETXATTR ioctls
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Move some tests to the copy_range group so they are distinct
from the copy group which refers to xfs_copy tests.
[Amir] Revert copy past EOF behavior change
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Check that if we write some data to a file, its inode gets evicted
(while its parent directory's inode is not evicted due to being in
use), then we rename the file and fsync it, after a power failure
the file data is not lost.
This currently passes on xfs, ext4 and f2fs but fails on btrfs. The
following patch for btrfs fixes it:
"Btrfs: fix data loss after inode eviction, renaming it, and fsync it"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We found some AIO write related bugs recently, so I think a AIO
random write test is needed. By the new aio-aio-write-verify.c tool,
we can do this easily.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify ciphertext for v1 encryption policies that use Adiantum to
encrypt file contents and file names.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify ciphertext for v1 encryption policies that use AES-128-CBC-ESSIV
to encrypt file contents and AES-128-CTS-CBC to encrypt file names.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify ciphertext for v1 encryption policies that use AES-256-XTS to
encrypt file contents and AES-256-CTS-CBC to encrypt file names.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Run fsstress, fsync every file and directory, simulate a power failure and
then verify that all files and directories exist, with the same data and
metadata they had before the power failure.
This test has found already 2 bugs in btrfs, that caused mtime and ctime of
directories not being preserved after replaying the log/journal and loss
of a directory's attributes (such a UID and GID) after replaying the log.
The patches that fix the btrfs issues are titled:
"Btrfs: fix wrong ctime and mtime of a directory after log replay"
"Btrfs: fix fsync not persisting changed attributes of a directory"
Running this test 1000 times:
- on xfs, no issues were found
- on ext4 it has resulted in about a dozen journal checksum errors (on a
5.0 kernel) that resulted in failure to mount the filesystem after the
simulated power failure with dmflakey, which produces the following
error in dmesg/syslog:
[Mon May 13 12:51:37 2019] JBD2: journal checksum error
[Mon May 13 12:51:37 2019] EXT4-fs (dm-0): error loading journal
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>
Max Reitz
Andreas Gruenbacher
Darrick J. Wong
Amir Goldstein
Christoph Hellwig
Filipe Manana
Theodore Ts'o
Lakshmipathi.G
Zorro Lang
Eric Biggers
Qu Wenruo
Jiufei Xue