Yang Xu reported a test failure in xfs/148 that I think comes from
extended attributes being returned in a different order than they were
set. Since order isn't important in this test, sort the output to make
it consistent.
Reported-by: Yang Xu <xuyang2018.ky@cn.fujitsu.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The only XFS-specific part of this test is the setup, so we can make
the rest a generic test. It's slow, though, as it needs to write 8GB
to convert a big unwritten extent to written.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This's a functional test case for mount --move operation, it verifies
below semantics:
---------------------------------------------------------------------------
| MOVE MOUNT OPERATION |
|**************************************************************************
|source(A)->| shared | private | slave | unbindable |
| dest(B) | | | | |
| | | | | | |
| v | | | | |
|**************************************************************************
| shared | shared | shared | shared & slave | invalid |
| | | | | |
|non-shared| shared | private | slave | unbindable |
***************************************************************************
NOTE: moving a mount residing under a shared mount is invalid.
This case uses fsstress to produce a little random load, to make
sure basic operations won't break the the moved mountpoints.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we clone part of an extent from a file to itself at a
different offset, fsync it, rewrite (COW) part of the extent from the
former offset, fsync it again, power fail and then mount the filesystem,
we are able to read the whole file and it has the correct data.
This is motivated by a bug found in btrfs which is fixed by a kernel patch
that has the following subject:
"Btrfs: fix missing data checksums after replaying a log tree"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/551 sometimes fails because it's killed by OOM killer.
That is because aio-dio-write-verify, which is called by
generic/551, tries to allocate memory even though the total
allocation size exceeds the available memory.
aio-dio-write-verify allocates memory according to the 'size'
argument, and generic/551 passes the argument.
Stop adding the argument when the total size is exceeds
the available memory.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>
Darrick J. Wong
Kusanagi Kouichi
Omar Sandoval
Zorro Lang
Filipe Manana
Masayoshi Mizuma
Qu Wenruo
Baihua Lu
Naohiro Aota
Xiaoli Feng
Amir Goldstein
Jan Kara