A test to perform reads/writes under various cgroups and verify that
I/Os are accounted properly according to cgroup aware writeback.
This is a generic test, but not all commonly used local filesystems
support cgroup aware writeback at the moment (i.e., XFS). Therefore,
this test currently requires ext4 or btrfs for the time being.
The common/cgroup2 file is copied from a separate cgroup related
patch from Shaohua Li that never made it upstream.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Shaohua Li <shli@fb.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>
If the XFS error injection knob directory exists but the knob itself
doesn't, then we know that this kernel doesn't support the knob and
can skip the test.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.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>
Filesystems are not required to try to fill the statx btime field
unless the caller actually sets STATX_BTIME. They're allowed to
volunteer that information "if it's cheap", but XFS doesn't
volunteer and there may be filesystems that support btime but not
cheaply.
Either way, we want to test btime on any filesystem that supports
it, cheaply or otherwise, so set STATX_BTIME when we're trying to
detect support for it.
[Eryu: fix _require_scratch_btime too]
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>
Refactor the kmemleak code to work correctly with sections. This
requires changing the location of the "is kmemleak enabled?" flag to
use /tmp instead of RESULT_BASE, scanning for leaks after every
test, and clarifying which functions get used when.
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>
Currently generic/075 and generic/112 have two extra fsx passes each
that exercise fsx with preallocation, which are only enabled for
XFS.
These tests can also be run with other file systems, given that the
XFS prealloc ioctls are implemented in generic code since the
addition of the fallocate system call. This also means a version of
XFS that does not support preallocation (e.g. because it always
writes out of place) can skip the prealloc tests while still
completing the normal fsx tests just fine.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Regression test for read corruption of compressed and shared extents
after punching holes into a file. The same extent is shared by the
same file in consecutive ranges (without other extents in between).
This is motivated by a bug recently found in btrfs for which there
is a patch for the linux kernel titled:
"Btrfs: fix corruption reading shared and compressed extents after hole
punching"
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
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>
When unlink() fails, that is, when the lock file is not deleted
successfully, variable we_created_lockfile is still set to 0.
On the next iteration, the 3 processes will not be able to
successfully create the lock file.
Signed-off-by: Cui Yue <cuiyue-fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test has the number of files/dirs created by xfsrestore hardcoded
in golden output.
When fsstress is added new ops, the number of files/dirs created with
the same random seed changes and this regularly breaks this test,
so when new fsstress ops are added they should be either added to the
dump test blacklist or golden output of this test needs to be ammended
to reflect the change.
The golden output includes only the file count reported by xfsrestore
and test does not even verify that this is the correct file count.
Instead, leave the golden output neutral and explicitly verify that
file count before and after the test are the same.
With this change, the test becomes agnostic to fsstress ops and we
could also stop blacklisting clone/dedup/copy ops if we want.
Signed-off-by: Amir Goldstein <amir73il@gmail.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/252 has a few feature tests, but misses checking for preallocation
support. Because of that it will fail instead of not being run for
and XFS file system in always COW mode.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Thanks to Darrick J. Wong find this issue! Current splice_f generates
file offset as below:
lr = ((int64_t)random() << 32) + random();
off2 = (off64_t)(lr % maxfsize);
It generates a pseudorandom 64-bit candidate offset for the
destination file where we'll land the splice data, and then caps the
offset at maxfsize (which is 2^63- 1 on x64), which effectively means
that the data will appear at a very high file offset which creates
large (sparse) files very quickly.
That's not what we want, and some case likes shared/009 will take
forever to run md5sum on lots of huge files.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Overlayfs might copy up data of file on first write of file (and
not necessarily upon open of file). So call falloc file opened
with O_RDWR and after that data must have been copied up.
[Eryu: add _require_xfs_io_command "falloc" to make sure underlying
fs have fallocate(2) support]
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Instead, call _cleanup_dump explicitly from a private _cleanup.
Remove the generic cleanup bits (rm $tmp.*) from _cleanup_dump.
The only xfs/dump test that had anything other than rm $tmp.* in
_cleanup in xfs/287, but that was _scratch_unmount, which is not
needed anyway.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Format the scratch device before using it, or else xfs_db will fail,
particularly if the previous test left a corrupt fs behind.
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>
Make sure that we still have the scratch directory after repairing our
corrupted filesystem, because repair could have nuked it.
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>
overlay/061 is currently the only overlay test that is expected to
fail on upstream kernel.
It is a flavor of test overlay/016 with mread in stead of pread.
The ro/rw inconsistencies related to file read()/write() API were
fixed with stacked file operations in v4.19, but the ro/rw
inconsistencies related to shared mmap read/write remain to be
fixed.
The test currently checks cache coherency between mmap read and file
write(), but this sort of cache coherency is a Linux implementation
detail not a requirement of the API.
Instead of mread vs. pwrite, check consistency of mread vs. mwrite
to shared mmap, which is required by the MMAP_SHARED API.
Because we can, perform the test on shared memory that maps files
that are already close and check also that mwrite after file is
closed is persistent. This adds test coverage for future overlayfs
writeback code.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Extend test 064 to check security.capability xattr is not lost over
copy-up of a metadata only file. This requires mounting overlay with
option metacopy=on and first trigger metadata only copy-up and then
trigger data copy-up.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a test case for a long existing bug, caused by
over-estimated metadata space_info::bytes_may_use.
There is one proposed patch for btrfs-progs to fix it, titled:
"btrfs-progs: balance: Sync the fs before balancing metadata chunks"
The test case itself is almost the same as btrfs/181, which uses
small files to bump the reserved space to trigger the false alert.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Brian Foster
Zorro Lang
Darrick J. Wong
Christoph Hellwig
Filipe Manana
Cui Yue
Amir Goldstein
Vivek Goyal
Qu Wenruo