Regression test to ensure that dquots are attached to the inode when
we're performing unwritten extent conversion after a directio write
and the extent mapping btree splits.
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>
Dave Chinner reports[1] that an appending AIO DIO write to the second
block of a zero-length file and an fallocate request to the first block
of the same file can race to set isize, with the user-visible end result
that the file size is set incorrectly to one block long. Write a small
test to reproduce the results.
[1] https://lore.kernel.org/linux-xfs/20191029100342.GA41131@bfoster/T/
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 fstests will remove $seqres.dmesg if nothing wrong
happened. It saves some space, but sometimes it may not provide
good enough history for developers to check.
For example, some unexpected dmesg from fs, but not serious enough
to be caught by current filter.
So instead of deleting the ordinary $seqres.dmesg, provide a new
config: KEEP_DMESG, to allow user to keep the dmesg by setting it to
"yes".
The default value for it is "no", which keeps the existing behavior
by deleting ordinary dmesg.
[Eryu: change it to a "yes"/"no" switch.]
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The new 'xfsquota' configuration for generic/050 doesn't filter out
SCRATCH_MNT properly and seems to be missing an error message in the
golden output. Fix both of these problems.
Fixes: e088479871 ("generic/050: Handle xfs quota special case with different output")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After this test is passed, checking filesystems will execute. Then
xfs_logprint will be failed and xfs_repair will take a long time
because there is not really creating the file system in this test
and wipefs executes before this test. So there is no need checking
filesystems.
Signed-off-by: Baihua Lu <lubaihua0331@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that when we have the no-holes feature enabled and a specific
metadata layout, if we punch a hole that starts at file offset 0 and
fsync the file, after replaying the log the hole exists.
This currently fails on btrfs but is fixed by a patch for the linux
kernel with the following subject:
"Btrfs: fix missing hole after hole punching and fsync when using NO_HOLES"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs/085 mount and works on $FLAKEY_DEV, but it's inspecting the
underlying $SCRATCH_DEV. Since writing to dm-flakey does not
invalidate page cache of $SCRATCH_DEV, the btrfs command can read a
stalled data from page cache. We should check the flakey device to
avoid such cache inconsistency.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Here will check the return code of mount option. So update it
to use _try_scratch_mount.
Signed-off-by: Xiaoli Feng <xifeng@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The first line of generic/563.out is wrong, the number should be
563, not 011. This mismatch will always cause testing fail.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We did not consistently remove trailing dot from umount output which
can presumably lead to false failures with particular versions of
util-linux. Make sure all umount output is properly filtered.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Instead of faking output for the case of XFS with quotas, just use a
different output file with appropriate output.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test gives false failure on ext2 filesystem as 64k file already
has indirect block and so space usage does not exactly match
expectation.
The test really needs to verify only whether quota accounting got
reenabled so just test using creating another empty file which is
not prone to these problems.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test generic/382 depends on filesystem allocating exactly 30M of blocks
when writing 30M file. This is not true for some filesystems - e.g. for
ext2 due to indirect blocks - while leads to false positive failures.
In this case, the test is not actually interested in comparing exact
usage, rather in verifying the ability to write 30M worth of data. So
instead of comparing 'xfs_quota report' output, just depend on detecting
error when writing files.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filesystems without journal can happily mount unrecovered filesystem
read-only which confuses this test. Handle this by providing
different expected output for filesystems without journal.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <guaneryu@gmail.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>
Verify that both full and incremental send operations can issue
clone operations when a file has extents that are shared with itself
(at different offsets of course).
This currently fails on btrfs but is addressed by a patch for the
kernel titled:
"Btrfs: send, allow clone operations within the same file"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a new helper that is similar to _count_extents() except that
extents that are shared several times by the file with itself
(reflinked at different file offsets) are accounted 1 time only,
instead of N times.
This is motivated by a subsequent test for btrfs that will use this
new helper, to verify that send streams are issuing reflink
operations.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The helper functions _count_extents() and _count_holes() open their
input file in RW mode to call fiemap, however opening it in RO mode
is enough. By opening them in RW mode it also makes it not possible
to use them against files residing in btrfs readonly snapshots for
example.
So just open the files in RO mode in these functions.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Making many small holes in 10M test file seems not very
helpful for test coverage and it takes too much time on
creating test files. In order to improve test speed we
adjust test file size to (10 * iosize) for iosize aligned
hole files and meanwhile add more test patterns for small
random holes and small empty file.
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With a recent change to xfs_io[1], the fsxattr.xflags output line
has added another flag column, so xfs/207 starts failing.
Rather than testing for an exact set of flags, test whether the
specific flag we are interested in is set or unset.
[1] xfs_io/lsattr: expose FS_XFLAG_HASATTR flag
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/317 will fail because execvp(cmd) is executed without permission,
where cmd is '$here/src/lstat64 $file', which is called by
$here/src/nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000"\
$here/src/lstat64 $file
So, you will see following output:
From user_ns
...
+execvp: Permission denied
nsexec runs the instruction '$here/src/lstat64 $file' as a regular user,
the regular user may not have permission to access path in '$here'.
Actually, it has been fixed in 4818302fbf ("xfstests: generic/317 use
relative paths..."), which then been modified by b7cecbea22 ("fstests:
Add path $here before src/<file>").
Fixes: b7cecbea22 ("fstests: Add path $here before src/<file>")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Qu Wenruo
Baihua Lu
Filipe Manana
Naohiro Aota
Xiaoli Feng
Zorro Lang
Amir Goldstein
Jan Kara
kaixuxia
Chengguang Xu
Eric Sandeen
Zhihao Cheng