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>
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>
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>
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>
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>
Older kernels don't have /sys/fs/btrfs. btrfs/010 will happily run
until it goes to check its work against sysfs and finds those files
don't exist. This patch introduces a require check to ensure that
the sysfs files are present before running.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
New fsstress operation breaks fs dump/restore testing which use
fsstress, e.g xfs/068.
In _create_dumpdir_stress_num, disable splice in fsstress so that we
dump exactly the same set of files and directories.
Quote Dave's comments for future reference
"
fsstress is just creating regular files differently. It has no
impact on xfsdump does except to change the number of files created
and the directory layout.
If this new functionality were creating a new type of file that
xfsdump has to handle, or adding new attributes or changing the
metadata of the existing files, then we want to make sure xfsdump is
tested against that, and so we'd be changing the golden output after
careful checking that both xfsdump and xfs_restore are working
correctly and the file count is correct.
But when all we are doing is creating normal, regular files just
with a different syscall, it makes no sense to perturb the existing
test then we have to go and validate that the new set of files being
tested is actually scanned correctly, is complete and correct. Using
a blacklist to avoid unnecessary perturbation such as in cases like
this is the right thing to do because we've had to determine if the
new functionality is a useful addition to xfsdump/restore test
coverage or not.
"
[Eryu: add Dave's comments in commit log for future reference]
Signed-off-by: Zorro Lang <zlang@redhat.com>
Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This commit tried to fix the brokennes of the kmemleak support but it
inadvertently broke the creation of the RESULT_BASE directory which lead to
problems creating check.time file. Turns out kmemleak support in xfstests has
more problems and it needs to be majorly refactor and this commit doesn't
really solve the problem. For the time being just revert to at least allow
older configuration files, which have explicitly set RESULT_BASE to work.
This reverts commit 7fc034868d.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Look for uninterpretable stringified constants in the ftrace format
description for xfs tracepoints.
[Eryu: add $CC_PROG definition and require it in test, also use
$DEBUGFS_MNT instead of hard coded path]
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 few tests require v4 filesystems and enforce this by disabling
crc's in the _scratch_mkfs call. However, if the user specified
MOUNT_OPTIONS that only work with v5 filesystems, these tests fail.
If we detect a test creating a v4 scratch filesystem, filter out
incompatible mount options that don't work on v4, such as
simultaneous group/project quota.
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>
With older util-linux(e.g. v2.17.2), running some tests(e.g.
generic/472, generic/495) got the following output:
-------------------------------------------------------
+mkswap: /mnt/xfstests/scratch/swap: warning: don't erase bootbits sectors
+ on whole disk. Use -f to force.
+mkswap: unable to relabel /mnt/xfstests/scratch/swap to system_u:object_r:swapfile_t:s0: Operation not supported
-------------------------------------------------------
1) Before commit c1f1b30 of util-linux, standard mkswap didn't zap bootbits
sectors and printed a warning until force option(i.e. -f) was given. We
define "mkswap -f" as MKSWAP_PROG and replace all standard mkswap with
$MKSWAP_PROG.
2) With mounting default SELinux context(e.g. system_u:object_r:root_t:s0),
standard mkswap tried to reset the type of default context to swapfile_t
if it is not swapfile_t, and then it failed and returned ENOTSUP expectedly
as we don't want to create any SELinux attr on purpose. standard mkswap
ignored this relabel error by commit d97dc0e of util-linux, but it still
reported the error before commit d97dc0e. We try to skip the reset step
in standard mkswap by mounting swapfile context directly.
Note:
We just mount swapfile context in related tests, and keep default context
in the rest of tests.
[Eryu: make mkswap a non-mandatory requirement and add comments on
"-f" option]
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In _init_kmemleak() we're touching a check_kmemleak file in
${RESULT_BASE} if ${DEBUGFS_MNT/kmemleak} exists as a marker that we
have to check for kmemleak output after running a test.
In 'check' we're calling _init_kmemleak() at around 60% of the file,
but ${RESULT_BASE} is created later at around 62% of the file,
causing the 'touch' in _init_kmemleak() to fail.
Create the ${RESULT_BASE} just after assigning the default value in
get_next_config()
[Eryu: check for mkdir failure and remove the $RESULT_BASE creation
in check.]
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In _create_dumpdir_stress_num, disable copyrange in fsstress so that we
dump exactly the same set of files and directories no matter how the xfs
is configured.
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>
In generic/519, filefrag command use FIBMAP ioctl(-B option) to print
output in extent format(-e option) on purpose and sync file(-s option),
so add _require_filefrag_options() to check if the command supports
all of these options.
References:
1) filefrag supports -e option by commit 2508eaa since e2fsprogs v1.42.7.
2) filefrag supports -B option by commit 5d5e01d since e2fsprogs v1.41.9.
3) filefrag supports -s option by commit e62847c since e2fsprogs v1.41.6.
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Check that the file system actually supports preallocation for defrag
tests that end up calling xfs_fsr, as they can't be supported in
always_cow mode.
[Eryu: add comments in code as well]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.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>
The leafn creation test doesn't work on some v4 filesystems
because the field names change. Rearrange the code somewhat so that it
works properly.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
A bug in file cloning/reflinking was recently found that afftected both
Btrfs and XFS, which was caused by allowing the cloning of an eof block
into the middle of a file when the eof is not aligned to the filesystem's
block size.
The fix consists of returning the errno -EINVAL to user space when the
arguments passed to the system call lead to the scenario of data
corruption. However this overlaps with some cases where the system call,
in Btrfs, returned -EOPNOTSUPP, which means we are trying to reflink
inline extents. That is unsupported in Btrfs due to the huge complexity
of supporting it (due to copying and trimming inline extents, deal with
eventual compression, etc).
We have a few btrfs test cases that verify that attempts to clone inline
extents result in a failure, and are currently expecting an -EINVAL error
message from the output of the cloner program. So create a filter that
converts error messages related to the -EOPNOTSUPP error to messages
related to the -EINVAL error, so that the test can run both on patched
and non-patched linux kernels.
The corresponding btrfs patch for the linux kernel is titled:
"Btrfs: fix data corruption due to cloning of eof block"
And the VFS change that introduces the -EINVAL error return was introduced
by the following linux kernel commit (landed in 4.20-rc1):
07d19dc9fbe9 ("vfs: avoid problematic remapping requests into partial EOF block")
The btrfs patch is not yet in Linus' tree (it was submitted around the
same time as this change) and the VFS change was introduced in 4.10-rc1.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When xfsdump is making multi-file dumps, the quota information are
written into the last dump file. However, the multi-file restore script
(as written) expects to see quota information restored by every dump
file and fails. This is silly, so fix 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>
On XFS, the only reliable way to clean out speculative post-eof
preallocations, delayed allocations, and speculative cow preallocations
is to cycle the filesystem mount. Since we're comparing the post-test
quota counts against a freshly quotacheck to look for leaks, it's fine
to cycle the mount. This eliminates sporadic quota count failures when
running xfstests with quotas enabled.
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>
We've had some problems lately with directories containing a single
leafn directory. It turns out that the populate script doesn't create
these, so teach it to do so.
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>
_require_btime() just check inode creation time feature on TEST_DIR
mountpoint, but generic/508 needs to do that check on SCRATCH_MNT
mountpoint. Let's add _require_scratch_btime() for that, meanwhile
handling scratch_{mkfs,mount,umount} inside the function to decouple
with caller.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>