Test that an incremental send operation succeeds, and produces the
correct results, after removing a directory and all its files, unmounting
the filesystem, mounting the filesystem again and creating a new file (or
directory).
This currently fails on btrfs, but is fixed by a patch that has the
following subject:
btrfs: send, fix wrong file path when there is an inode with a pending rmdir
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a regression test for the issue fixed by the kernel commit titled
"btrfs: correctly calculate item size used when item key collision happens"
In this case, we'll simply rename many forged filename that cause collision
under a directory to see if rename failed and filesystem is forced readonly.
Signed-off-by: ethanwu <ethanwu@synology.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When I compiled xfstests using the gcc(version 4.8.5), the following error occurred:
t_enospc.c: In function 'enospc_test':
t_enospc.c:88:2: error: 'for' loop initial declarations are only allowed in C99 mode
for (int i = 0; i < size; i++) {
^
Signed-off-by: Feiyu Zhu <zhufy.jy@cn.fujitsu.com>
Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.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>
Avoid the following warning by replacing deprecated
attr_set with setxattr:
---------------------------------------------------
warning: 'attr_set' is deprecated: Use setxattr or lsetxattr instead [-Wdeprecated-declarations]
---------------------------------------------------
Also remove unneeded flags, <attr/attributes.h> and $(LIBATTR).
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.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>
This patch updates btrfs/215 to work with latest upstream kernel. That's
required since commit 324bcf54c449 ("mm: use limited read-ahead to satisfy read")
changed readahead logic to always issue a read even if the RA pages are
set to 0. This results in 1 extra io being issued so the counts in the
test should be incremented by 1. Also use the opportunity to update the
commit reference since it's been merged in the upstream kernel.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The mount options uqnoenforce and qnoenforce no longer cause 'usrquota'
to be emitted in /proc/mounts, so there is a regression in xfs/513. Fix
it by using proper output option uqnoenforce.
You'll need kernel commit 237d7887ae72 ("xfs: show the proper user
quota options") to pass the test.
[Eryu: add kernel commit info in commit log]
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If TEST_DEV is recreated by check, FSTYP derived from TEST_DEV
previously could be changed too and might not reflect the reality.
So source common/rc again with correct FSTYP to get fs-specific
configs, e.g. common/xfs.
For example, using this config-section config file, and run section
ext4 first then xfs, you can see:
our local _scratch_mkfs routine ...
./common/rc: line 825: _scratch_mkfs_xfs: command not found
check: failed to mkfs $SCRATCH_DEV using specified options
local.config:
[default]
RECREATE_TEST_DEV=true
TEST_DEV=/dev/sda5
SCRATCH_DEV=/dev/sda6
TEST_DIR=/mnt/test
SCRATCH_MNT=/mnt/scratch
[ext4]
MKFS_OPTIONS="-b 4096"
FSTYP=ext4
[xfs]
FSTYP=xfs
MKFS_OPTIONS="-f -b size=4k"
Tested-by: Ritesh Harjani <riteshh@linux.ibm.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
There is a conflict with the user visible statx bits 'mount root' and
'dax'. The kernel is changing the dax bit to correct this conflict.[1]
Adjust _check_s_dax() to use the new bit. Because DAX tests do not run
on root mounts, STATX_ATTR_MOUNT_ROOT should always be 0. Therefore,
check for the old flag and fail the test if that occurs.
[1] https://lore.kernel.org/lkml/3e28d2c7-fbe5-298a-13ba-dcd8fd504666@redhat.com/
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-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>
For the moment cross quota realms renames has been disabled in CephFS
after a bug has been found while renaming files created and truncated.
This allowed clients to easily circumvent quotas.
Link: https://tracker.ceph.com/issues/48203
Signed-off-by: Luis Henriques <lhenriques@suse.de>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
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>
Replace all the $MKFS_PROG.$FSTYP invocations with $MKFS_PROG -t $FSTYP.
The mkfs wrapper binary knows how to search the user's $PATH to find the
appropriate mkfs delegate, which the author uses to switch between
development and distro versions of various tools.
Unfortunately, using "$MKFS_PROG.$FSTYP" means that the shell only looks
in the same directory as the mkfs wrapper, which means that we can end
up mixing different tool versions when this is the case.
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>
Make sure that _scratch_xfs_populate always installs its files on the
data device even if the test config selects rt by default.
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>
TLDR: If systemd is available, run each test in its own temporary
systemd scope. This enables the test harness to forcibly clean up all
of the test's child processes (if it does not do so itself) so that we
can move into the post-test unmount and check cleanly.
I frequently run fstests in "low" memory situations (2GB!) to force the
kernel to do interesting things. There are a few tests like generic/224
and generic/561 that put processes in the background and occasionally
trigger the OOM killer. Most of the time the OOM killer correctly
shoots down fsstress or duperemove, but once in a while it's stupid
enough to shoot down the test control process (i.e. tests/generic/224)
instead. fsstress is still running in the background, and the one
process that knew about that is dead.
When the control process dies, ./check moves on to the post-test fsck,
which fails because fsstress is still running and we can't unmount.
After fsck fails, ./check moves on to the next test, which fails because
fsstress is /still/ writing to the filesystem and we can't unmount or
format.
The end result is that that one OOM kill causes cascading test failures,
and I have to re-start fstests to see if I get a clean(er) run.
So, the solution I present in this patch is to teach ./check to try to
run the test script in a systemd scope. If that succeeds, ./check will
tell systemd to kill the scope when the test script exits and returns
control to ./check. Concretely, this means that systemd creates a new
cgroup, stuffs the processes in that cgroup, and when we kill the scope,
systemd kills all the processes in that cgroup and deletes the cgroup.
The end result is that fstests now has an easy way to ensure that /all/
child processes of a test are dead before we try to unmount the test and
scratch devices. I've designed this to be optional, because not
everyone does or wants or likes to run systemd, but it makes QA easier.
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>
_get_file_block_size is intended to return the size (in bytes) of the
fundamental allocation unit for a file. This is required for remapping
operations like fallocate and reflink, which can only operate on
allocation units. Since the XFS realtime volume can be configure for
allocation units larger than 1 fs block, we need to factor that in here.
Note that ext* with bigalloc does not allocations to be aligned to the
cluster size, so no update is needed there.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Chandan Babu R <chandanrlinux@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>
IO_URING is a new feature for GNU/Linux system, if someone case of
xfstests tests this feature, better to check if current system
supports it, or need _notrun.
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>
In commit 65cd8e8a8e ("fscrypt-crypt-util: fix IV incrementing for
--iv-ino-lblk-32") I mistakenly decreased the size of fscrypt_iv to 24
bytes, which is the most that is explicitly needed by any of the IV
generation methods. However, Adiantum encryption takes a 32-byte IV, so
the buffer still needs to be 32 bytes, with any extra bytes zeroed.
So restore the size to 32 bytes.
This fixes a buffer overread that caused generic/550 and generic/584 to
sometimes fail, depending on the build of the fscrypt-crypt-util binary.
(Most of the time it still worked by chance.)
Fixes: 65cd8e8a8e ("fscrypt-crypt-util: fix IV incrementing for --iv-ino-lblk-32")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>