It turns out that repquota (which reports in units of 1k blocks) reports
rounded up numbers when the fs blocksize is 512 bytes. However, xfs_io
stat always reports block counts in units of 512 bytes. If the number
of (512b) file blocks is not an even number, the "$3 / 2" expression
will round down, causing the test to fail. Round up to the nearest 1k
to match repquota's behavior.
Reported-by: zlang@redhat.com
Fixes: 6b04ed0545 ("generic: test unwritten extent conversion extent mapping quota accounting")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The 'grep -c "error"' check was causing false positive results for
cifs.ko when running it with 'echo 1 > /proc/fs/cifs/cifsFYI'.
That is, the test would fail when cifs.ko prints out a non-error
message like this:
[ 2320.903987] fs/cifs/smb2maperror.c: Mapping SMB2 status code 0x80000006 to POSIX err -61
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Suggested-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If the arbitrary char/block devices 1:1 do not exist in the system,
the tests fail.
Use /dev/zero and loop device instead of made up device numbers.
Reposted-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test a scenario were we fsync a range of a file and have a power
failure. We want to check that after a power failure and mounting
the filesystem, we do not end up with a missing file extent
representing a hole. This applies only when not using the NO_HOLES
feature.
This currently fails on btrfs but it is fixed by a patch for the kernel
that has the following subject:
"Btrfs: fix missing file extent item for hole after ranged fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Now btrfs can delete subvolumes based in ther subvolume id. This
makes easy for the user willing to delete a subvolume that cannot be
accessed by the mount point, since btrfs allows to mount a specific
subvolume and hiding the other from the mount point.
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In the blockgroup type single with nodesize 64K, the relocation of
the bg containing the swapfile is not being attempted during the
resize. So due to this the resize is successful and does not
generate the required 'Text file busy' error message as in the
golden output and so the testcase fails.
Fix this by replacing the mkfs created chunk with the bigger kernel
created chunk using balance, and then fill it up to the full. Upsize
to 3x of fssize once instead of first to 2G and then to 3G. Also
drop the unnecessary downsize to 2G step.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test case needs at least 3g scratch device space, check for it
before starting the test case.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The minimum accepted allocsize mount option value is page size, which
causes the particular test to fail in architectures where page size >
block size. Fix it by basing the value on the platform page size rather
than the block size as obtained from mkfs. In addition add a filter so
that different values can be used without breaking the golden output.
Signed-off-by: Anthony Iliopoulos <ailiopoulos@suse.com>
Reviewed-by: Zorro Lang <zlang@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>
Create a helper to run xfs_admin on the scratch device, then
refactor all tests to use it.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If xfs_io's utimes command cannot interpret the arguments that are
given to it, it will print out "Bad value for [am]time". Detect
when this happens and drop the file out of the test entirely.
This is particularly noticeable on 32-bit platforms and the largest
timestamp seconds supported by the filesystem is INT_MAX. In this
case, the maximum value we can cram into tv_sec is INT_MAX, and
there is no way to actually test setting a timestamp of INT_MAX + 1
to test the clamping.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Apparently we don't have any tests which exercise the code path in
Btrfs that has to split up direct I/Os for RAID stripes. Add one to
catch the bug fixed by "btrfs: fix RAID direct I/O reads with
alternate csums".
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Recently LTP upstream removed some ext4 tests[1]. And two of them
is still valid to keep. So I transport those two tests here.
ext4-nsec-timestamps, which is used to test nanosec timestamps of
ext4, rewrite into ext4/043 and 044. ext4-subdir-limit, which is
used to test subdirectory limit of ext4, rewrite into ext4/045.
[1] https://marc.info/?l=linux-fsdevel&m=157190623919681&w=2
Signed-off-by: Sun Yong <yosun@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test currently assumes a file system block size of 4k. It will
work just fine on any user-specified block size, though.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Move the check for dax from the individual target scripts into
_require_dm_target. This fixes up a couple of missed tests that are
failing due to the lack of dax support (such as tests requiring
dm-snapshot).
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
A handful of minor changes went into xfs_repair output in the
last push, so add a few more filters and change the resulting
expected output.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Now we just kill fdatasync_work process and wait nothing after the
test, so a busy unmount failure may appear if the fdatasync syscall
doesn't return in time.
umount: /tmp/scratch: target is busy.
mount: /tmp/scratch: /dev/sdb already mounted on /tmp/scratch.
!!! failed to remount /dev/sdb on /tmp/scratch
This patch waits the xfs_io fdatasync subprocess exit to make sure
_check_scratch_fs success.
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Generic/484 tests functionality that isn't really related to file
systems, and has failed every since it was added. Remove it as it
serves no puropse in xfstests.
[Eryu: also remove src/t_locks_execve.c and its entries in
src/Makefile and .gitignore]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a testcase for a corner that I missed when trying to fix gap
extents for btrfs. We would end up with gaps if we hole punched past
isize and then extended past the gap in a specific way. This is a
simple reproducer to show the problem, and has been properly fixed by my
patches now.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test several scenarios of cloning operations where the source range
includes inline extents. They used to not be supported on btrfs
because their implementation was not straightforward, and therefore
these operations used to fail with errno EOPNOTSUPP on older
kernels.
This currently fails on any released kernel. It passes only when the
patch with the following subject is applied:
"Btrfs: implement full reflink support for inline extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test case, btrfs/112, tests that some clone operations that have a
range covering inline extents fail with either -EOPNOTSUPP or -EINVAL.
These cases were unsupported on btrfs because they used to lead to file
corruptions and were not trivial to implement.
But there's now a patchset that adds support for them, and the relevant
patch of that patchset has the following subject:
"Btrfs: implement full reflink support for inline extents"
So just remove these tests from test case btrfs/112, since this test
case is about testing only the unsupported reflink operations. A new
test case that verifies that these cases now work, as long as some other
new cases, will follow in another patch.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This allows us to run all those tests which simulate disk failures
using dmerror.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>