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>
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>
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>
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>
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>
cgroup writeback accounting does not track partition level
statistics. Instead, I/O is accounted against the parent device. As
a result, the test fails if the scratch device happens to be a
device partition. Since parent level stats are potentially polluted
by factors external to the test, wrap the scratch device in a
loopback device to guarantee the test always runs on a top-level
block device.
Reported-by: Boyang Xue <bxue@redhat.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test for a race condition where a duplicate filename could be created in
an encrypted directory while the directory's encryption key was being
added concurrently.
generic/595 was already failing on ubifs due to this bug, but only by
accident. This new test detects the bug on both ext4 and ubifs. I
wasn't able to get it to detect the bug on f2fs.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add this test to check for regression which was reported when ext4 bmap
aops was moved to use iomap APIs. jbd2 calls bmap() kernel function
from fs/inode.c which was failing since iomap_bmap() implementation earlier
returned 0 for block addr > INT_MAX.
This regression was fixed with following kernel commit [1]
commit b75dfde1212991b24b220c3995101c60a7b8ae74
("fibmap: Warn and return an error in case of block > INT_MAX")
[1]: https://patchwork.ozlabs.org/patch/1279914
w/o the kernel fix we get below errors and mount fails
[ 1461.988701] run fstests generic/613 at 2020-10-27 19:57:34
[ 1530.406645] ------------[ cut here ]------------
[ 1530.407332] would truncate bmap result
[ 1530.408956] WARNING: CPU: 0 PID: 6401 at fs/iomap/fiemap.c:116 iomap_bmap_actor+0x43/0x50
[ 1530.410607] Modules linked in:
[ 1530.411024] CPU: 0 PID: 6401 Comm: mount Tainted: G W
<...>
[ 1530.511978] jbd2_journal_init_inode: Cannot locate journal superblock
[ 1530.513310] EXT4-fs (dm-1): Could not load journal inode
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Test allocation strategies of the file system and validate space
anomalies as reported by the system versus the allocated by the
program.
The test is motivated by a bug in ext4 systems where-in ENOSPC is
reported by the file system even though enough space for allocations is
available[1].
[1]: https://patchwork.ozlabs.org/patch/1294003
Linux kernel patch series that fixes the above regression:
53f86b170dfa ("ext4: mballoc: add blocks to PA list under same spinlock
after allocating blocks")
cf5e2ca6c990 ("ext4: mballoc: refactor ext4_mb_discard_preallocations()")
07b5b8e1ac40 ("ext4: mballoc: introduce pcpu seqcnt for freeing PA to
improve ENOSPC handling")
8ef123fe02ca ("ext4: mballoc: refactor ext4_mb_good_group()")
993778306e79 ("ext4: mballoc: use lock for checking free blocks while
retrying")
Suggested-by: Ritesh Harjani <riteshh@linux.ibm.com>
Co-authored-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There is a regression that recent XFS_LITINO(mp) update causes
xfs_attr_shortform_bytesfit() returns maxforkoff rather than 0.
Therefore, one result is
"ASSERT(new_size <= XFS_IFORK_SIZE(ip, whichfork));"
Add a regression test in fstests generic to look after that since
the testcase itself isn't xfs-specific.
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Fix these tests that rely on the allocation unit size of a file, which
might not necessarily be the fs block size.
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>
After fsx supports IO_URING read/write, add a test to do IO_URING
direct-IO test by fsx
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
After fsx supports IO_URING read/write, add a test to do IO_URING
soak test of fsx.
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 keep overwriting an entire file, either with buffered
writes or direct IO writes, the number of used blocks reported by stat(2)
is never zero while the writes and writeback are in progress.
This is motivated by a bug in btrfs and currently fails on btrfs only. It
is fixed a patchset for btrfs that has the following patches:
btrfs: fix missing delalloc new bit for new delalloc ranges
btrfs: refactor btrfs_drop_extents() to make it easier to extend
btrfs: fix race when defragging that leads to unnecessary IO
btrfs: update the number of bytes used by an inode atomically
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that after doing a memory mapped write to an empty file, a call to
stat(2) reports a non-zero number of used blocks.
This is motivated by a bug in btrfs where the number of blocks used does
not change. It currenly fails on btrfs and it is fixed by a patch that
has the following subject:
"btrfs: fix missing delalloc new bit for new delalloc ranges"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that encryption nonces are unique and random, where randomness is
approximated as "incompressible by the xz program".
This gets indirectly tested by generic/399, but there are some gaps.
It's good to test for this directly too.
This test runs and passes on ext4 and f2fs. It doesn't currently run on
ubifs because _get_encryption_nonce() isn't implemented for ubifs yet.
(At some point I'll probably switch _get_encryption_nonce() to use
FS_IOC_GET_ENCRYPTION_NONCE, which was added in Linux 5.7. But for now
I'd like to keep the tests using it runnable on older kernels too.)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/398 contains workarounds to allow for renames of encrypted files
to fail with different error codes. However, these error codes were
fixed up by kernel commits f5e55e777cc9 ("fscrypt: return -EXDEV for
incompatible rename or link into encrypted dir") and 0c1ad5242d4f
("ubifs: switch to fscrypt_prepare_rename()").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/395 contains workarounds to allow for some of the fscrypt ioctls
to fail with different error codes. However, the error codes were all
fixed up and documented years ago:
- FS_IOC_GET_ENCRYPTION_POLICY on ext4 failed with ENOENT instead of
ENODATA on unencrypted files. Fixed by commit db717d8e26c2
("fscrypto: move ioctl processing more fully into common code").
- FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of EEXIST
on encrypted files. Fixed by commit 8488cd96ff88 ("fscrypt: use
EEXIST when file already uses different policy").
- FS_IOC_SET_ENCRYPTION_POLICY failed with EINVAL instead of ENOTDIR
on nondirectories. Fixed by commit dffd0cfa06d4 ("fscrypt: use
ENOTDIR when setting encryption policy on nondirectory").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/397 contains workarounds to allow for kernel bugs where trying
to open or create files in an encrypted directory without the encryption
key failed with ENOENT, EACCES, or EPERM instead of the expected ENOKEY.
However, all these bugs have been fixed. ext4 and f2fs were fixed years
ago by commit 54475f531bb8 ("fscrypt: use ENOKEY when file cannot be
created w/o key"). ubifs was fixed by commit b01531db6cec ("fscrypt:
fix race where ->lookup() marks plaintext dentry as ciphertext").
It's been long enough, so update the test to expect the correct behavior
only, so we don't accidentally reintroduce the wrong behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Here won't be "scratch mount failed" messages when mounting SCRATCH_DEV
failed, because _scratch_mount exits early by invoking the following_fail.
_scratch_mount
{
_try_scratch_mount $* || _fail "mount failed"
}
The message is useless and redundant. So drop it.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If one of the subtests of generic/127 fails, we proceed with the
rest of the tests, potentially overwriting useful data. This makes
it stop as soon as any of the subtests fails.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Starting with version 2.41 of libcap, the output of the getcap program
changed and therefore some existing tests fail when the installed version
of libcap is >= 2.41 (the latest version available at the moment is 2.44).
The change was made by the following commit of libcap:
commit 177cd418031b1acfcf73fe3b1af9f3279828681c
Author: Andrew G. Morgan <morgan@kernel.org>
Date: Tue Jul 21 22:58:05 2020 -0700
A more compact form for the text representation of capabilities.
While this does not change anything about the supported range of
equivalent text specifications for capabilities, as accepted by
cap_from_text(), this does alter the preferred output format of
cap_to_text() to be two characters shorter in most cases. That is,
what used to be summarized as:
"= cap_foo+..."
is now converted to the equivalent text:
"cap_foo=..."
which is also more intuitive.
So add a filter to change the old format to the new one, an helper that
calls getcap with that filter, make existing tests use the new helper and
update their golden output to match the new output format of getcap.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When using old version(such as getfattr 2.4.46) getfattr command, it
has the following output,
touch file
setfattr -n user.a file
getfattr --absolute-names -n user.a file
user.a
on new getfattr, it reports the following output,
getfattr --absolute-names -n user.a file
user.a=""
The {=""} will break the golden image, so use _getfattr to filter
the redundant ="" at the end if it has.
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>
The test checks "noatime" mount option effect, which makes it reasonable
to include the test into atime test group along with generic/003 and
generic/192 tests.
The test properly depends on _require_atime and for certain filesystems
the test is not run:
[not run] atime related mount options have no effect on cifs
Signed-off-by: Vladimir Zapolskiy <vladimir@tuxera.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Zorro Lang
Eric Biggers
Murphy Zhou
Ritesh Harjani
Brian Foster
Pratik Rajesh Sampat
Gao Xiang
Darrick J. Wong
Filipe Manana
Xiao Yang
Yang Xu
Matthew Wilcox
Vladimir Zapolskiy