xfs_admin in xfsprogs 5.11 has a bug wherein a caller who specifies an
external log device forces xfs_db to be invoked, potentially with zero
command arguments. When this happens, xfs_db will wait for input on
stdin, which causes fstests to hang. Since xfs_admin is not an
interactive tool, redirect stdin from /dev/null to prevent this issue.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Teach _scratch_xfs_admin to support passing the realtime device to
xfs_admin so that we can actually test xfs_admin functionality with
those setups.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create a couple of helper functions to get and set the XFS copy on write
preallocation garbage collection interval.
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/502 currently creates a default of 30k unlinked files per CPU.
While this completes in a reasonable amount of time on systems with
lesser numbers of CPUs, this scales poorly on high CPU count systems
that are otherwise testing smaller default filesystems. For example,
on an 80xcpu box and a 15GB (4 AG) XFS filesystem, xfs/502 requires
3 hours to complete. The same test on a 4xcpu vm (or the 80xcpu
hardware with an 80AG filesystem instead of the default of 4AGs)
completes in a little over 5 minutes. This is a rather severe
thrashing breakdown that doesn't add much value to the test
coverage.
Address this problem by scaling the file count to the AG count of
the filesystem rather than the CPU count of the test system. Since
the AG count is likely to be less than the CPU count, bump the
default scaling factor a bit from 30k per CPU to 50k per AG. From
there, larger counts can still be exercised via the global load
factor configuration.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The minimum length space allocator (i.e.
xfs_bmap_exact_minlen_extent_alloc()) depends on the underlying
filesystem to be fragmented so that there are enough one block sized
extents available to satify space allocation requests.
xfs/{532,533,538} tests issue space allocation requests for metadata
(e.g. for blocks holding directory and xattr information). With
realtime filesystem instances, these tests would end up fragmenting
the space on realtime device. Hence minimum length space allocator
fails since the regular filesystem space is not fragmented and hence
there are no one block sized extents available.
Thus, this commit disables realtime inherit flag (if any) on root
directory so that space on data device gets fragmented rather than
realtime device.
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Reported-by: Darrick J. Wong <djwong@kernel.org>
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>
xfs/{529,531,532,534,535} attempt to create test files after injecting
reduce_max_iextents error tag. Creation of test files fails when using a
multi-block directory test configuration because,
1. A directory can have a pseudo maximum extent count of 10.
2. In the worst case a directory entry creation operation can consume
(XFS_DA_NODE_MAXDEPTH + 1 + 1) * (Nr fs blocks in a single directory block)
extents.
With 1k fs block size and 4k directory block size, this evaluates to,
(5 + 1 + 1) * 4
= 7 * 4
= 28
> 10 (Pseudo maximum inode extent count).
This commit fixes the issue by creating test files before injecting
reduce_max_iextents error tag.
Reported-by: Darrick J. Wong <djwong@kernel.org>
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandanrlinux@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
chown command is being executed on $testfile which is actually
deleted just before the execution of quota inode extent count
overflow test. Hence the test was not getting exercised at all.
This commit fixes the bug by using $fillerdir as the target of chown
command.
Signed-off-by: Chandan Babu R <chandanrlinux@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Write data into a file and then enable DAX on the file immediately,
the written data which is still in the buffer should be synchronized
to disk instead of discarded when the corresponding inode is evicted.
It's a regression test for commit 88149082bb8e ("fs: Handle
I_DONTCACHE in iput_final() instead of generic_drop_inode()")
Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since commit 77573fa310d9, toggling FS_XFLAG_DAX on an existing file can make
S_DAX on the file change immediately when all applications close the file.
As a result, we don't need the redundant drop cache and umount & mount cycle.
Signed-off-by: Xiaoli Feng <xifeng@redhat.com>
Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The ltp/fsstress always fails on io_uring_queue_init() by returnning
ENOMEM. Due to io_uring accounts memory it needs under the rlimit
memlocked option, which can be quite low on some setups, especially
on 64K pagesize machine. root isn't under this restriction, but
regular users are. So only g/233 and g/270 which use $qa_user to run
fsstress are failed.
To avoid this failure, set max locked memory to unlimited before
doing fsstress, then restore it after test done.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Otherwise, if xfs_io doesn't support this command, it will report
that filesystem fails on this testcase.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a new test to make sure the xfs_db path command works the way the
author thinks it should.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Non-partitionable devices, like zoned block devices, aren't showing
up in in /proc/partitions and therefore we cannot rely on it to get
a device's size.
Use blockdev --getsz to get the block device size.
Cc: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we set a capability on a file but not on the next files we
create, send/receive operations only apply the capability to the first
file, the one for which we have set a capability.
This is motivated by a regression that started to happen with kernel 5.8,
caused by an incompatibility between kernel commit 89efda52e6b693
("btrfs: send: emit file capabilities after chown") and a workaround for
send/receive added to btrfs-progs several years ago by btrfs-progs
commit 123a2a085027e ("btrfs-progs: receive: restore capabilities after
chown"). That workaround in btrfs-progs was added in btrfs-progs 4.1.
That kernel commit ended up fixing the bugs the btrfs-progs commit
targeted, as well as other bugs around btrfs send and capabilities.
However it did not play nice with the btrfs-progs workaround.
The kernel fix was backported to all stable kernels and the btrfs-progs
workaround was later removed from btrfs-progs by commit 81d8ea9346c6ee
("btrfs-progs: receive: remove workaround for setting capabilities"),
introduced in btrfs-progs 5.11.
The test currently fails on any environment using kernel 5.8+ and a
btrfs-progs version between 4.1 and 5.10. Updating btrfs-progs to
version 5.11 makes the test pass.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
wenli xie reported a buffer cache deadlock when an overlayfs is mounted
atop xfs and overlayfs tries to replace a single-nlink file with a
whiteout file. This test reproduces that deadlock.
Reported-by: wenli xie <wlxie7296@gmail.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Combine these two helpers into a single generic function so that we can
use it in the next patch to test a regression when running overlayfs
atop xfs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a couple of regression tests for "xfs: make sure the rt allocator
doesn't run off the end" and "xfs: ensure that fpunch, fcollapse, and
finsert operations are aligned to rt extent size".
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Casefold rename test should check if renaming a file to an equivalent
name fails as expect (e.g. renaming from "file.txt" to "FILE.TXT") and
`mv` correctly identifies that those names refers to the same file.
Currently, the test doesn't do what is expected given that it doesn't
have the file to be renamed, and `mv` returns "No such file or
directory". Fix that by creating test files and checking the correct
output.
Fixes: 12b7dddbc2 ("generic: Add tests for filename casefolding feature")
Signed-off-by: André Almeida <andrealmeid@collabora.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Escape SCRATCH_DEV variable so it prints its name, instead of printing
the value. If the value is "", the error message will not be very
informative.
Signed-off-by: André Almeida <andrealmeid@collabora.com>
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The device name of a secondary storage device isn't all that important,
but the size is.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create fifos when populating the scratch filesystem for completeness.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
I just noticed that the fs population helper creates a chardev file
"S_IFBLK" on the scratch filesystem. This seems bogus (particularly
since we actually also create a chardev named S_IFCHR) so fix up the
mknod calls.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Sun Ke
Darrick J. Wong
Brian Foster
Chandan Babu R
Xiao Yang
Zorro Lang
Chao Yu
Johannes Thumshirn
Filipe Manana
André Almeida