When we set up a fstests run, preserve the path xfs_metadump binary with
an $XFS_METADUMP_PROG wrapper, like we do for the other xfsprogs tools.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
XFS has a regression where it failed to check shutdown status in the
write fault path. This produced an iomap warning if the page
happened to recently fail a writeback attempt because writeback
failure can clear Uptodate status on the page.
Add a test for this scenario to help ensure mapped write failures
are handled as expected in the event of filesystem shutdown.
Upstream commit e4826691cc7e ("xfs: restore shutdown check in mapped
write fault path") fixed this bug.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Overlayfs added the ability to set inode flags (e.g. chattr +i) in
kernel 5.10 by commit 61536bed2149 ("ovl: support [S|G]ETFLAGS and
FS[S|G]ETXATTR ioctls for directories").
Icenowy Zheng reported [1] a regression in that commit that causes
a deadlock when setting inode flags on lower dir.
The regression was fixed by commit b854cc659dcb ("ovl: avoid deadlock
on directory ioctl") and applied to kernel 5.10.15.
[1] https://lore.kernel.org/linux-unionfs/20210101201230.768653-1-icenowy@aosc.io/
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Chengguang Xu reported [1] that append-only flag is lost on copy-up.
I had noticed that for directories, immutable flag can also be lost
on copy up (when parent is copied up). That's an old overlayfs bug.
Fixing this requires some VFS API changes that Miklos has proposed[2]
[1] https://lore.kernel.org/linux-unionfs/20201226104618.239739-1-cgxu519@mykernel.net/
[2] https: //lore.kernel.org/linux-fsdevel/20210203124112.1182614-1-mszeredi@redhat.com/
[Eryu: referencing the thread of the pending fix]
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For overlayfs tests we need to be able to setflags on existing
(lower) files.
t_immutable -C test_dir
Creates the test area and sets flags, but it also allows setting flags
on an existing test area.
t_immutable -R test_dir
Removes the flags from existing test area, but does not remove the files
in the test area.
To setup a test area with file without flags, need to run the -C and -R
commands.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
commit 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR
ioctls for directories") makes the comment in test header inaccurate.
Fix the comment to include this information.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
All the remaining tests that use _require_no_rtinherit can be adapted to
ignore SCRATCH_RTDEV or to force files to be created on the data device.
This makes the helper unnecessary and increases test coverage, so remove
this helper.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The filestreams allocator can only be selected for files that reside on
the data volume. In commit ee3e0010, we sprinkled calls to
_require_no_rtinherit in the filestreams tests so that there wouldn't be
regressions reported if the filesystem is formatted with -d rtinherit=1.
This unnecessarily limits test coverage because userspace can control
the device selection parameters quite easily with xfs_io chattr. Make
the filestreams tests unset SCRATCH_RTDEV so that the allocator isn't
thrown off by the rtbitmap consuming space on the data device.
Fixes: ee3e0010 ("xfs/realtime: add _require_no_rtinherit function")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The build fails on SLE11 as the function aligned_alloc is not
available there. Replace it by memalign that has the same semantics
and is commonly used in fstests code base. aligned_alloc has
additional requirements on the alignment and buffer size but that is
ok as the buffer is defined in multiples of the alignment.
Signed-off-by: David Sterba <dsterba@suse.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If the original value of $MKFS_OPTIONS contained a block size value
having 'k' as a suffix (e.g. -b size=4k), then the newly constructed
value of $MKFS_OPTIONS will have 'k' suffixed to the value of
$blocksize. $blocksize itself is specified in units of bytes. Hence
having 'k' suffixed to this value will result in an incorrect block
size.
This commit fixes the bug by conditionally filtering out the 'k'
suffix from block size option present in the original value of
$MKFS_OPTIONS.
Signed-off-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test for incorrect ondisk dquot type checking that
was introduced in Linux 5.9. The bug is that we can no longer switch a
V4 filesystem from having group quotas to having project quotas (or vice
versa) without logging corruption errors. That is a valid use case, so
add a regression test to ensure this can be done.
[Eryu: add _require_check_dmesg and print the 'corruption' dmesg]
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
when run make, show:
swapon.c:135:3: warning: 'p' may be used uninitialized in this function
[-Wmaybe-uninitialized]
memcpy(p, buf, BUF_SIZE);
^~~~~~~~~~~~~~~~~~~~~~~~
This's a fake uninitialized warning.
gcc think the 'p' can be used uninitialized at here when verb is
TEST_MWRITE_BEFORE_AND_MWRITE_AFTER:
case TEST_MWRITE_BEFORE_AND_MWRITE_AFTER:
memcpy(p, buf, BUF_SIZE);
break;
But, if verb is TEST_MWRITE_BEFORE_AND_MWRITE_AFTER, the 'p' will be
initialized by:
switch (verb) {
case TEST_MWRITE_BEFORE_AND_MWRITE_AFTER:
case TEST_MWRITE_BEFORE:
p = mmap(NULL, BUF_SIZE, PROT_WRITE | PROT_READ, MAP_SHARED,
Silent the warning by initializing p to NULL anyway.
Signed-off-by: Sun Ke <sunke32@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This case print both fio stdout and stderr to .full file, that cause
we miss some unexpected failures when there's a bug. For example:
file:io_u.c:1803, func=io_u error, error=Block device required
This's an regression issue we find on a downstream kernel, not in
upstream. So release unexpected fio error output to find more issues.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
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>
Test that when the lazytime mount option is enabled, updates to atime,
mtime, and ctime get persisted in the cases when they should be.
This test currently runs on ext4, f2fs, and xfs, since it's limited to
filesystems that support the shutdown ioctl.
This test currently passes on ext4 and f2fs. On xfs, kernel
commit 1e249cb5b7fc ("fs: fix lazytime expiration handling in
__writeback_single_inode()") is needed for the test to pass, since xfs
had a bug where it didn't persist timestamps when it should have.
[Eryu: add shutdown metadata atime group]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When testing arm machine, this case fails because ps > bs and kernel
doesn't introduced commit c8cc88163f40 ("ext4: Add support for
blocksize < pagesize in dioread_nolock"). Only skip this case when
kernel complains about bs!=ps error, so we can find dioread_nolock
mount regression in the future.
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>
Simple tests of the upcoming mkfs.xfs config file feature. First we
have some simple tests of properly formatted config files, then
improperly formatted config files, and finally we try to spot
conflicts between config file options and the cli.
[dchinner: updated for new libinih-based implementation.]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There is a bug that, when btrfs is beyond qgroup limit, touching a file
could crash btrfs.
Such beyond limit situation needs to be intentionally created, e.g.
writing 1GiB file, then limit the subvolume to 512 MiB.
As current qgroup works pretty well at preventing us from reaching the
limit.
This makes existing qgroup test cases unable to detect it.
The regression is introduced by commit c53e9653605d ("btrfs: qgroup:
try to flush qgroup space when we get -EDQUOT"), and the fix is
commit 6f23277a49e6 ("btrfs: qgroup: don't commit transaction when
we already hold the handle")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1178634
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since coreutils upstream v8.32~47
commit a99ab266110795ed94a9cb4d2765ddad9c4310da
Author: Jeff Layton <jlayton@kernel.org>
Date: Thu Sep 19 11:59:45 2019 -0400
ls: use statx instead of stat when available
stat(1) starts to use statx(2) call.
In some testcase, if file does not exist, this breaks golden
output like this:
-stat: cannot stat 'SCRATCH_MNT/xxx': No such file or directory
+stat: cannot statx 'SCRATCH_MNT/xxx': No such file or directory
Add this filter to fix it, and add this filter to testcases that
need it.
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation correctly issues clone operations
for a file that had different parts of one of its extents cloned into
itself, at different offsets, and a large part of that extent was
overwritten, so all the reflinks only point to subranges of the extent.
This currently fails on btrfs but is fixed by a patch for the kernel that
has the following subject:
"btrfs: send, fix invalid clone operations when cloning from the same file and root"
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 verifies btrfs' free objectid management. I.e it ensures that
the first objectid is always 256 in an fs tree.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
ext4, xfs should not fail swapon on fallocated file. Currently if this
fails the fstst was not returning a failure. Fix those for given
filesystems (for now added ext4/xfs).
There were some regressions which went unnoticed due to this in ext4
tree, which later got fixed as part of this patch [1]
[1]: https://patchwork.ozlabs.org/patch/1357275
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filesystems e.g. ext* and XFS supports swapon by default and an error
returned with swapon should be treated as a failure.
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
XFS has an issue where superblock counters may not be properly
synced when recovery occurs via a read-only mount. This causes the
filesystem to become inconsistent after unmount. To cover this test
case, update generic/388 to switch between read-only and read-write
mounts to perform log recovery.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Brian Foster
Amir Goldstein
David Sterba
Chandan Babu R
Sun Ke
Zorro Lang
Eric Sandeen
Eric Biggers
Yang Xu
Darrick J. Wong
Qu Wenruo
Murphy Zhou
Filipe Manana
Nikolay Borisov
Ritesh Harjani