Now that we don't have any libattr dependencies anymore, get rid of all
the build system hooks.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
attr_list is deprecated, so just call llistxattr directly. This is a
bit involved, since attr_remove_f was highly dependent on libattr
structures. Note that attr_list uses llistxattr internally and
llistxattr is limited to XATTR_LIST_MAX, so this doesn't result in any
loss of functionality.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We might have URING #defined at build time, but be running on a kernel
which does not support it.
For that reason, we should not exit with an error if
io_uring_queue_init() fails with ENOSYS. We can just note the lack of
support and skip all future io_uring operations.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
attr_remove is deprecated, so replace it with lremovexattr.
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>
We shouldn't feed sizeof() to strncpy as the string length. Just use
snprintf, which at least doesn't have the zero termination problems.
In file included from /usr/include/string.h:495,
from ../src/global.h:73,
from fsx.c:16:
In function 'strncpy',
inlined from 'main' at fsx.c:2944:5:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning:
'__builtin_strncpy' specified bound 4096 equals destination size
[-Wstringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'strncpy',
inlined from 'main' at fsx.c:2914:4:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning:
'__builtin_strncpy' specified bound 1024 equals destination size
[-Wstringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>
The fsx contains different read and write operations, especially the
AIO and general IO read/write. The fsx chooses one kind of read/write
from AIO and general IO to run. To make the logic clear, use a common
fsx_rw() function to swith between these two kinds of read/write.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If io_submit or io_getevents fails, the do_aio_rw() won't free the
"buf" and cause memory leak.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The original number(128) of aio events for io_setup too big. When try
to run lots of fsstress processes(e.g. -p 1000) always hit io_setup
EAGAIN error, due to the nr_events exceeds the limit of available
events. Due to each fsstress process only does once libaio read/write
operation each time. So reduce the aio events number to 1, to make more
fsstress processes can do AIO test.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
IO_URING is a new feature of curent linux kernel, add basic IO_URING
read/write into fsstess to cover this kind of IO testing.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We have very similar code that generates the destination range for clone,
dedupe and copy_file_range operations, so avoid duplicating the code three
times and move it into a helper function.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
While running generic/521 I've had fsx taking a lot of CPU time and not
making any progress for several hours. Attaching gdb to the fsx process
revealed that fsx was in the loop that generates the ranges for a
copy_file_range operation, in particular the loop seemed to never end
because the range defined by 'offset2' kept overlapping with the range
defined by 'offset'.
So far this happened one time only in one of my test VMs with generic/521.
Fix this by breaking out of the loop after trying 30 times, like we
currently do for dedupe operations, which results in logging the operation
as skipped.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
While running generic/457 I've had fsx taking a lot of CPU time and not
making any progress for over an hour. Attaching gdb to the fsx process
revealed that fsx was in the loop that generates the ranges for a clone
operation, in particular the loop seemed to never end because the range
defined by 'offset2' kept overlapping with the range defined by 'offset'.
So far this happened two times in one of my test VMs with generic/457.
Fix this by breaking out of the loop after trying 30 times, like we
currently do for dedupe operations, which results in logging the operation
as skipped.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Currently we are limiting the range for zero range operations to stay
within the i_size boundary. This is not optimal because like this we lose
coverage of the filesystem's zero range implementation, since zero range
operations are allowed to cross the i_size. Fix this by limiting the range
to 'maxfilelen' and not 'file_size', and update the 'file_size' after each
zero range operation if needed.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We are never using the FALLOC_FL_KEEP_SIZE flag for zero range operations
even when we intend to use it. So fix it by setting that flag for the
call to fallocate(2) if the 'keep_size' parameter is true.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Support 64-bit operation counts so that we can run long-soak tests for
more than 2 billion fsxops.
I figured that testcalls and simulatedopcount should both be signed
because numops is also signed. Granted, I guess numops is signed so
that we can set it to the magic value -1 and have fsx run "forever".
[Eryu: add Darrick's explanation about why we change testcalls to a
signed value.]
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>
fsx has a closeopen option where it will close and then re-open the
file. This is handy, but what is really more useful is to drop the file
from cache completely, so add a drop_caches into this operation so that
the file is read back completely from disk to be really evil.
[Eryu: fix drop cache failure number to stay within 190]
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
I was running down a i_size problem and was missing the failure until
the next iteration of fsx operations because we do the file size check
_before_ the closeopen operation. Move it after the closeopen operation
so we can catch problems where the file gets messed up on disk.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Compilation failed on Fedora 20 because stdbool.h is not included in
xfs/platform_defs-x86_64.h or xfs/linux.h on Fedora 20.
Also, yang xiao fixed similar problem(commit 234f51ebbd) for fsx.c in
2016.2, but after that, fsstress.c started to use bool variable without
including stdbool.h file. It may fail on old linux distributions, so
fix it.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On 32-bit systems, the offsets are 'unsigned long' (32-bit) which means
that we must cast the explicitly to unsigned long long before feeding
them to llabs. Without the type conversion we fail to sign-extend the
llabs parameter, try to make a copy/clone/dedupe call with overlapping
ranges, and fsx aborts and the test fails.
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>
Most operations are just looking for a base directory to generate a file
in, they don't actually need a directory specifically. Add FT_ANYDIR to
cover both directories and subvolumes, and then use this in all the
places where it makes sense.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Snapshots are just fancy subvolumes, add this ability so we can stress
snapshot creation. We get the deletion with SUBVOL_DELETE.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This patch adds support to fsstress for creating and deleting subvolumes
on a btrfs file system. We link in the libbtrfsutil library to handle
the mechanics of creating and deleting subvolumes instead of duplicating
the ioctl logic. There is code to check if we're on a btrfs fs at
startup time and if so 0 out the frequency of the btrfs specific
operations.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The source file id and parentid are overwritten by del_from_flist()
call, so should show the actually values.
Signed-off-by: kaixuxia <kaixuxia@tencent.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Eric Sandeen
Darrick J. Wong
Zorro Lang
Filipe Manana
Josef Bacik
Yang Xu
kaixuxia