Boris Burkov [Tue, 23 Jan 2024 19:56:59 +0000 (11:56 -0800)]
btrfs: Remove btrfs/303
This test was reproducing a bug triggered by creating a subvolume qgroup
before creating the subvolume itself with a snapshot.
The kernel patch:
btrfs: forbid creating subvol qgroups
explicitly prevents that and makes it fail with EINVAL. I could "fix"
this test by expecting the EINVAL message in the output, but at that
point it would simply be a test that creating a subvolume and
snapshotting it works with qgroups, which is adequately tested by other
tests which focus on accurately measuring shared/exclusive usage in
various snapshot/reflink scenarios. To avoid confusion, I think it is
best to simply delete this test.
Signed-off-by: Boris Burkov Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
When testing on a MTD with a rather small erase block
size, the default max_attr limit can be too much and the
test will fail.
Instead compute the actual limit.
Signed-off-by: Richard Weinberger <richard@nod.at> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs/604: Make test as _notrun for higher blocksizes filesystem
If we have filesystem with blocksize = 64k, then the falloc value will
be huge (falloc_size=5451.33GB) which makes fallocate fail hence causing
the test to fail. Instead make the testcase "_notrun" if the initial
fallocate itself fails.
Signed-off-by: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Sat, 27 Jan 2024 20:44:17 +0000 (07:14 +1030)]
btrfs: verify the read behavior of compressed inline extent
[BUG]
There is a report about reading a zstd compressed inline file extent
would lead to either a VM_BUG_ON() crash, or lead to incorrect file
content.
[CAUSE]
The root cause is a incorrect memcpy_to_page() call, which uses
incorrect page offset, and can lead to either the VM_BUG_ON() as we may
write beyond the page boundary, or writes into the incorrect offset of
the page.
[TEST CASE]
The test case would:
- Mount with the specified compress algorithm
- Create a 4K file
- Verify the 4K file is all inlined and compressed
- Verify the content of the initial write
- Cycle mount to drop all the page cache
- Verify the content of the file again
- Unmount and fsck the fs
This workload would be applied to all supported compression algorithms.
And it can catch the problem correctly by triggering VM_BUG_ON(), as our
workload would result decompressed extent size to be 4K, and would
trigger the VM_BUG_ON() 100%.
And with the revert or the new fix, the test case can pass safely.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Zorro Lang [Sun, 28 Jan 2024 15:56:53 +0000 (23:56 +0800)]
xfs: test xfs_growfs with too-small size expansion
This's a regression test of 84712492e6da ("xfs: short circuit
xfs_growfs_data_private() if delta is zero").
If try to do growfs with "too-small" size expansion, might lead to a
delta of "0" in xfs_growfs_data_private(), then end up in the shrink
case and emit the EXPERIMENTAL warning even if we're not changing
anything at all.
Signed-off-by: Zorro Lang <zlang@redhat.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Pavel Reichl [Wed, 6 Dec 2023 07:15:25 +0000 (08:15 +0100)]
xfs/598: Add missing "fixed_by" hints
Kernel patches, the very same as for xfs/597, are necessary for scrub
to function as expected.
_check_xfs_filesystem: filesystem on /dev/sda3 failed scrub
xfs_scrub -v -d -n output ***
EXPERIMENTAL xfs_scrub program in use! Use at your own risk!
Phase 1: Find filesystem geometry.
/mnt/scratch: using 2 threads to scrub.
Phase 2: Check internal metadata.
Info: AG 1 superblock: Optimization is possible. (scrub.c line 212)
Info: AG 2 superblock: Optimization is possible. (scrub.c line 212)
Info: AG 3 superblock: Optimization is possible. (scrub.c line 212)
Phase 3: Scan all inodes.
Corruption: inode 131 (0/131) directory entries: Repairs are required. (scrub.c line 196)
Phase 5: Check directory tree.
Info: /mnt/scratch: Filesystem has errors, skipping connectivity checks. (phase5.c line 392)
Phase 7: Check summary counters.
203.0MiB data used; 5 inodes used.
64.2MiB data found; 5 inodes found.
5 inodes counted; 5 inodes checked.
/mnt/scratch: corruptions found: 1
/mnt/scratch: Re-run xfs_scrub without -n.
end xfs_scrub output
mount output ***
Signed-off-by: Pavel Reichl <preichl@redhat.com> Reviewed-by: Bill O'Donnell <bodonnel@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Su Yue [Mon, 29 Jan 2024 23:51:04 +0000 (07:51 +0800)]
common/rc: improve block_size support for bcachefs
mkfs.bcachefs now supports option '--block_size' to allow
custom block_size.
Add the pattern to set def_blksz if MKFS_OPTIONS contains the
option in _scratch_mkfs_sized.
Also let mkfs.bcachefs decide blocksize if no option is given in
MKFS_OPTIONS or _scratch_mkfs_sized parameter.
Signed-off-by: Su Yue <glass.su@suse.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Su Yue [Mon, 29 Jan 2024 23:51:03 +0000 (07:51 +0800)]
fstests: introduce MKFS_BCACHEFS_PROG for bcachefs
mkfs.bcachefs supports force overwrite when option '-f' is given:
$ mkfs.bcachefs --help | grep force
-f, --force
There are some tests which call _scratch_mkfs multiple times
e.g. tests/generic/171. Without '-f' in MKFS_OPTIONS,
these tests just hang in overwrite confirmation.
After this commit, MKFS_BCACHEFS_PROG will contains ' -f' so
we don't have to add '-f' to MKFS_OPTIONS manually to make
these tests pass.
It also fixes generic/466 which unsets MKFS_OPTIONS causing
that test hangs in mfks.bcachefs waiting for confirmation of
the force overwrite.
Signed-off-by: Su Yue <glass.su@suse.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Tue, 21 Nov 2023 22:39:09 +0000 (14:39 -0800)]
generic: add test for custom crypto data unit size
Add a test that verifies the on-disk format of encrypted files that use
a crypto data unit size that differs from the filesystem block size.
This tests the functionality that was introduced in Linux 6.7 by kernel
commit 5b1188847180 ("fscrypt: support crypto data unit size less than
filesystem block size").
This depends on the xfsprogs patch
"xfs_io/encrypt: support specifying crypto data unit size"
(https://lore.kernel.org/r/20231013062639.141468-1-ebiggers@kernel.org)
which adds the '-s' option to the set_encpolicy command of xfs_io.
As usual, the test skips itself when any prerequisite isn't met.
[zlang: add _wants_kernel_commit]
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Tue, 21 Nov 2023 22:39:08 +0000 (14:39 -0800)]
common/encrypt: support custom data unit size
Make _require_scratch_encryption() and
_require_encryption_policy_support() support the new '-s' option to
set_encpolicy to specify a custom value of log2_data_unit_size.
Likewise, make _verify_ciphertext_for_encryption_policy() accept an
argument "log2_dusize=*" to cause it to use the specified data unit size
for the test and verify that the file contents are encrypted as expected
for that data unit size.
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Eric Biggers [Tue, 21 Nov 2023 22:39:06 +0000 (14:39 -0800)]
fscrypt-crypt-util: rename block to data unit
Rename the --block-size option to --data-unit-size, and rename the
--block-number option to --data-unit-index.
This does not change any functionality, but this avoids confusion now
that the kernel supports the case where the crypto data unit size is not
the same as the filesystem block size. fscrypt-crypt-util cares about
the crypto data unit size, not the filesystem block size.
Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Omar Sandoval [Tue, 19 Dec 2023 18:34:37 +0000 (10:34 -0800)]
btrfs: test snapshotting a deleted subvolume
This is a regression test for patch "btrfs: don't abort filesystem when
attempting to snapshot deleted subvolume". Without the fix, the
filesystem goes read-only and prints a warning. With the fix, it should
fail gracefully with ENOENT.
btrfs: add fstest for overwriting a file partially with RST
Add a test writing 128k to an empty file with one stripe already
pre-filled on-disk. Then overwrite a portion of the file in the middle.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs: add fstests to write 128k to a RST filesystem
Add a test writing 128k to a file on an empty filesystem formatted with a
raid-stripe-tree.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs: add fstest for writing to a file at an offset with RST
Add a fstest writing 4k at offset 64k to a file with one RAID tripe
already pre-filled for a raid-stripe-tree formatted file system.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs: add fstest for 8k write spanning two stripes on raid-stripe-tree
Add a test-case writing 8k to a raid-stripe-tree formatted filesystem with
one stripe pre-filled to 60k so the 8k are split into a 4k write finishing
stripe 1 and a 4k write starting the next stripe.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
btrfs: add fstest for stripe-tree metadata with 4k write
Test a simple 4k write on all RAID profiles currently supported with the
raid-stripe-tree.
Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
[Fixed the test statement and trailing white space in the .out file.] Signed-off-by: Zorro Lang <zlang@kernel.org>
Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
[ add trailing whitespace and the version filter ] Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Fri, 29 Dec 2023 06:27:39 +0000 (14:27 +0800)]
common: add _filter_trailing_whitespace
The command 'btrfs inspect-internal dump-tree -t raid_stripe'
introduces trailing whitespace in its output.
Apply a filter to remove it. Used in btrfs/30[4-8][.out].
Signed-off-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
The new overlayfs mount options lowerdir+,datadir+ don't fit well
into any of the existing _overlay_scratch_mount* helpers.
Add this new helper to reduce a common pattern of custom mount options.
Suggested-by: Zorro Lang <zlang@kernel.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 10 Jan 2024 18:27:28 +0000 (13:27 -0500)]
generic/732: don't run it on NFS
This test sets up two independent superblocks with the same backend
server, and then does RENAMES of the same files in the two servers. This
is basically trying to simulate the case where two clients are competing
to rename files in the same directory on the same server.
This test would usually pass vs. an NFSv4 server that doesn't have dfdd2630a7398 ("nfsd: fix change_info in NFSv4 RENAME replies"), because
the client would end up improperly invalidating the dcache for the whole
dir after most RENAMEs.
However, this test doesn't (and shouldn't) pass on NFS, because the
client has no idea that a rename has happened on the second mount. The
expected behavior for the NFS client is for it to use the cache timeouts
in this case, which is what it now does with the above server bug fixed.
Exempt NFS from running this test, since we don't expect it to pass.
Cc: Yongcheng Yang <yoyang@redhat.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Jeff Layton [Wed, 10 Jan 2024 18:27:27 +0000 (13:27 -0500)]
generic/465: don't run it on NFS
This test kicks off a thread that issues a read against a file, while
writing to the file in 1M chunks. It expects that the reader will see
either the written data or a short read.
NFS allows DIO reads and writes to run in parallel. That means that it's
possible for them to race and the reader to see NULLs in the file if
things get reordered.
Just skip this test on NFS, since we can't guarantee that it will
reliably pass.
Chandan Babu R [Thu, 11 Jan 2024 11:58:27 +0000 (17:28 +0530)]
_scratch_xfs_mdrestore: Pass scratch log device when applicable
Metadump v2 supports dumping contents of an external log device. This commit
modifies _scratch_xfs_mdrestore() and _xfs_mdrestore() to be able to restore
metadump files which contain data from external log devices.
The callers of _scratch_xfs_mdrestore() must set the value of $SCRATCH_LOGDEV
only when all of the following conditions are met:
1. Metadump is in v2 format.
2. Metadump has contents dumped from an external log device.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Chandan Babu R [Thu, 11 Jan 2024 11:58:25 +0000 (17:28 +0530)]
common/xfs: Do not append -a and -o options to metadump
xfs/253 requires the metadump to be obfuscated. However _xfs_metadump() would
append the '-o' option causing the metadump to be unobfuscated.
This commit fixes the bug by modifying _xfs_metadump() to no longer append any
metadump options. The direct/indirect callers of this function now pass the
required options explicitly.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Chandan Babu R <chandanbabu@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Call _require_scratch_xfs_scrub so that the test is _notrun on kernels
without online scrub support.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Call _require_scratch_xfs_scrub so that the test is _notrun on kernels
without online scrub support.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Add a helper to call _supports_xfs_scrub with $SCRATCH_MNT and
$SCRATCH_DEV.
[zlang: rename the _scratch_require_xxx to _require_scratch_xxx]
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs: check that the mountpoint is actually mounted in _supports_xfs_scrub
Add a sanity check that the passed in mount point is actually mounted
to guard against actually calling _supports_xfs_scrub before
$SCRATCH_MNT is mounted.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
src/dbtest.c requires 'gdbm-ndbm.h' or 'ndbm.h', both of which are
supplied by 'libgdbm-compat-dev' in the latest Ubuntu LTS. However,
this package is not a dependency of the currently listed packages.
Therefore, add it explicitly to the necessary packages list.
Naohiro Aota [Fri, 22 Dec 2023 02:56:22 +0000 (11:56 +0900)]
fstests: btrfs: use proper filter for subvolume deletion
Test cases btrfs/208, 233, 276 does not use _filter_btrfs_subvol_delete()
to process "btrfs subvolume delete" command's output. So, the following
diff occurs even with a previous fix.
Recent btrfs-progs commit 5c91264d2dfc ("btrfs-progs: subvol delete:
print the id of the deleted subvolume") added the id of the deleted
subvolume to "Delete subvolume" print format.
As a result, btrfs/001 now always fail by the output difference.
_require_sparse_files: rewrite as a direct test instead of a black list
_require_sparse_files was implemented as a list of filesystems known not to
support sparse files, and therefore it missed some cases.
However, if sparse files do not work as expected during a test, the risk
is that the test will write out to the disk all the zeros that would
normally be unwritten. This amounts to at least 4 TB for the generic/129
test, and therefore there is a significant media wear-out concern here.
Adding more filesystems to the list of exclusions would not scale and
would not work anyway because CIFS backed by SAMBA is safe, while CIFS
backed by Windows Server 2022 is not (because the specific write
patterns found in generic/014 and generic/129 cause it to ignore the
otherwise-supported request to make a file sparse).
Mitigate this risk by rewriting the check as a small-scale test that
reliably triggers Windows misbehavior. The black list becomes unneeded
because the same test creates and detects non-sparse files on exfat and
hfsplus.
Signed-off-by: Alexander Patrakov <patrakov@gmail.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 13 Dec 2023 22:34:45 +0000 (14:34 -0800)]
generic/735: skip this test if we cannot finsert at pos 1M
Add a _require_congruent_file_oplen to screen out filesystem
configurations that can't start a finsert operation at file pos 1M
because the fs block size isn't congruent with 1048576. For example,
xfs realtime with 28k rt extents.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 13 Dec 2023 22:34:33 +0000 (14:34 -0800)]
generic/615: fix loop termination failures
On 6.7-rc2, I've noticed that this test hangs unpredictably because the
stat loop fails to exit. While the kill $loop_pid command /should/ take
care of it, it clearly isn't.
Set up an additional safety factor by checking for the existence of a
sentinel flag before starting the loop body. In bash, "[" is a builtin
so the loop should run almost as tightly as it did before.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 4 Dec 2023 18:58:57 +0000 (20:58 +0200)]
overlay: prepare for new lowerdir+,datadir+ tests
In preparation to forking tests for new lowerdir+,datadir+ mount options,
prepare a helper to test kernel support and pass datadirs into mount
helpers in overlay/079 test.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 11 Dec 2023 06:52:24 +0000 (08:52 +0200)]
overlay: Add tests for nesting private xattrs
If overlayfs xattr escaping is supported, ensure:
* We can create "overlay.*" xattrs on a file in the overlayfs
* We can create an xwhiteout file in the overlayfs
We check for nesting support by trying to getattr an "overlay.*" xattr
in an overlayfs mount, which will return ENOTSUPP in older kernels.
Signed-off-by: Alexander Larsson <alexl@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Murphy Zhou [Fri, 15 Dec 2023 11:55:05 +0000 (19:55 +0800)]
generic: drop caches while freeze
This's a bug reproducer for a downstream kernel, upstream linux has
fixed this issue "indirectly". When the superblock is frozen and
reclaim attempts to process certain inodes that require transactions
to break down, such as those with post-eof or COW fork blocks, a
deadlock might happen.
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
generic: Add integrity tests with synchronous directio
This test covers data & metadata integrity check with directio with
o_sync flag and checks the file contents & size after sudden fileystem
shutdown once the directio write is completed. ext4 directio after iomap
conversion was broken in the sense that if the FS crashes after
synchronous directio write, it's file size is not properly updated.
This test adds a testcase to cover such scenario.
Man page of open says that -
O_SYNC provides synchronized I/O file integrity completion, meaning write
operations will flush data and all associated metadata to the underlying
hardware
Reported-by: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 5 Dec 2023 16:39:20 +0000 (16:39 +0000)]
generic: test reading a large directory while renaming its files
Test that on a fairly large directory if we keep renaming files while
holding the directory open and doing readdir(3) calls, we don't end up
in an infinite loop.
This exercise a bug that existed in btrfs and was fixed in kernel 6.5
by commit 9b378f6ad48c ("btrfs: fix infinite directory reads").
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Baokun Li [Fri, 24 Nov 2023 11:53:56 +0000 (19:53 +0800)]
generic: regression test of ext4_lblk_t overflow
Append writes to a file with logical block numbers close to 0xffffffff and
observe if a kernel crash is caused by ext4_lblk_t overflow triggering
BUG_ON at ext4_mb_new_inode_pa(). This is a regression test for commit bc056e7163ac ("ext4: fix BUG in ext4_mb_new_inode_pa() due to overflow")
Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Mon, 20 Nov 2023 21:10:55 +0000 (13:10 -0800)]
btrfs/301: require_no_compress
btrfs/301 makes detailed size calculations to test squota edge cases
which rely on assumptions that break down with compression enabled.
Fix it by disabling the test with compression. Compression + squotas
still gets quite solid test coverage via squotas support in fsck and
normal compression enabled fstests runs.
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
overlay/026: Fix test expectation for newer kernels
The test checks the expectaion from old kernels that set/get of
trusted.overlay.* xattrs is not supported on an overlayfs filesystem.
New kernels support set/get xattr of trusted.overlay.* xattrs, so adapt
the test to check that either both set and get work on new kernel, or
neither work on old kernel.
Signed-off-by: Alexander Larsson <alexl@redhat.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Mon, 4 Dec 2023 15:45:10 +0000 (15:45 +0000)]
btrfs: add some tests to the 'compress' group
There are several btrfs test that exercise compression in one way or
another but are not listed as part of the 'compress' group, so add them
to that group.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Boris Burkov [Fri, 1 Dec 2023 21:09:45 +0000 (13:09 -0800)]
btrfs/303: use quota rescan wrapper
This new test called quota rescan directly rather than with the new
wrapper. As a result, it failed with -O squota in MKFS_OPTIONS. Using
the wrapper, it skips the rescan and passes again.
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Brian Foster [Wed, 29 Nov 2023 20:16:14 +0000 (15:16 -0500)]
generic/459: improve shutdown/read-only check to accommodate bcachefs
generic/459 occasionally fails on bcachefs because the deliberately
induced I/O errors caused by exhausting the overprovisioned thin
pool can lead to filesystem shutdown. This test considers this
expected behavior on certain fs', but only checks for the ext4
remount read-only behavior. bcachefs does a similar emergency
read-only transition in response to certain I/O errors, but it
behaves more similar to an XFS shutdown and doesn't necessarily
reflect "ro" state in the mount table (unless induced by userspace).
Since the test already runs a touch command to help trigger the ext4
error handling sequence, this can be tweaked to serve double duty
and also more accurately detect read-only status on bcachefs.
Refactor into a small helper, check for touch command failure, and
consider the fs read-only if either that or the mount entry check
indicates it.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Bill O'Donnell <bodonnel@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Omar Sandoval [Mon, 30 Oct 2023 21:00:15 +0000 (14:00 -0700)]
xfs: test refilling AGFL after lots of btree splits
This is a regression test for patch "xfs: fix internal error from AGFL
exhaustion"), which is not yet merged. Without the fix, it will fail
with a "Structure needs cleaning" error.
Signed-off-by: Omar Sandoval <osandov@osandov.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Thu, 16 Nov 2023 17:30:43 +0000 (09:30 -0800)]
misc: update xfs_io swapext usage
Since the new 'exchange range' functionality is no longer a VFS level
concept, the xfs_io swapext -v options have changed. Update fstests to
reflect this new reality.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Thu, 16 Nov 2023 17:30:37 +0000 (09:30 -0800)]
misc: privatize the FIEXCHANGE ioctl for now
I'm abandoning (for now) efforts to bring atomic file content exchanges
to the VFS. The goal here is to reduce friction in getting online fsck
merged, so Dave and I want to take this back to being a private XFS
ioctl so we can explore with it for a while before committing it to the
stable KABI.
Shift all the existing FIEXCHANGE usage to XFS_IOC_EXCHANGE_RANGE, and
try to pick it up from xfs_fs_staging.h if the system xfslibs-dev
package has such an animal.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Yang Xu [Thu, 16 Nov 2023 07:33:15 +0000 (02:33 -0500)]
xfs/263: Remove mkfs.xfs data section argument
On machine with using raid, this case will trigger
the following error:
==== NO CRC ====
+mkfs.xfs: small data volume, ignoring data volume stripe unit 512 and stripe width 512
== Options: rw ==
== Options: usrquota,rw ==
mkfs.xfs generates this error since xfsprogs commit 42371fb36
("mkfs: ignore data blockdev stripe geometry for small filesystems").
It disables automatic detection of stripe unit and width if the
data device is less than 1GB.
But, since xfstests commit baaa392c("xfs/263: don't hardcode inode numbers in output"),
we don't care the inode number. So let's remove this data section size argument
instead of increasing this size to 1G, then we can solve this false
positive.
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Qu Wenruo [Tue, 14 Nov 2023 02:59:13 +0000 (13:29 +1030)]
fstests: btrfs: test snapshot creation with existing qgroup
[BUG]
There is a sysbot regression report about transaction abort during
snapshot creation, which is caused by the new timing of qgroup creation
and too strict error check.
[FIX]
The proper fix is already submitted, with the title "btrfs: do not abort
transaction if there is already an existing qgroup".
[TEST]
The new test case would reproduce the regression by:
- Create a subvolume and a snapshot of it
- Record the subvolumeid of the snapshot
- Re-create the fs
Since btrfs won't reuse the subvolume id, we have to re-create the fs.
- Enable quota and create a qgroup with the same subvolumeid
- Create a subvolume and a snapshot of it
For unpatched and affected kernel (thankfully no release is affected),
the snapshot creation would fail due to aborted transaction.
- Make sure the subvolume id doesn't change for the snapshot
There is one very hacky attempt to fix it by avoiding using the
subvolume id, which is completely wrong and would be caught by this
extra check.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 13 Nov 2023 17:08:30 +0000 (09:08 -0800)]
xfs: test unlinked inode list repair on demand
Create a test to exercise recovery of unlinked inodes on a clean
filesystem. This was definitely possible on old kernels that on an ro
mount would clean the log without processing the iunlink list.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 13 Nov 2023 17:08:24 +0000 (09:08 -0800)]
common: make helpers for ttyprintk usage
A handful of tests write things to /dev/ttyprintk to make it easier to
pinpoint where in a test something went wrong. This isn't entirely
robust, however, because ttyprintk is an optional feature. In the grand
tradition of kernel design there's also a /dev/kmsg that does nearly the
same thing, is also optional, and there's no documentation spelling out
when one is supposed to use one or the other.
So.
Create a pair of helpers to append messages to the kernel log. One
simply writes its arguments to the kernel log, and the other writes
stdin to the kernel log, stdout, and any other files specified as
arguments.
Underneath the covers, both functions will send the message to
/dev/ttyprintk if available. If it isn't but /dev/kmsg is, they'll
send the messages there, prepending a "[U]" to emulate the only
discernable difference between ttyprintk and kmsg.
If neither are available, then either /dev or the kernel aren't allowing
us to write to the kernel log, and the messages are not logged. The
second helper will still write the messages to stdout.
If this seems like overengineered nonsense, then yes it is.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 13 Nov 2023 17:08:39 +0000 (09:08 -0800)]
generic: test reads racing with slow reflink operations
XFS has a rather slow reflink operation. While a reflink operation is
running, other programs cannot read the contents of the source file,
which is causing latency spikes. Catherine Hoang wrote a patch to
permit reads, since the source file contents do not change. This is a
functionality test for that patch.
[zlang@ adds `_supported_fs generic`]
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Catherine Hoang <catherine.hoang@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Wed, 8 Nov 2023 04:28:57 +0000 (12:28 +0800)]
common/btrfs: add _btrfs_get_fsid() helper
We have two instances of reading the btrfs fsid by using the command
'btrfs filesystem show <mnt>' turn this into an easy-to-use helper
function and also use it.
Suggested-by: David Sterba <dsterba@suse.cz> Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Thu, 2 Nov 2023 11:28:22 +0000 (19:28 +0800)]
btrfs/219: add to the auto group
Add this test case back to the auto group which reverts the
commit e2e7b549380a ("fstests: btrfs/219: remove it from auto group") since
the previously missing kernel commit 5f58d783fd78 ("btrfs: free device in
btrfs_close_devices for a single device filesystem") has already been
integrated.
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Thu, 2 Nov 2023 11:28:21 +0000 (19:28 +0800)]
btrfs/219: cloned-device mount capability update
This test case checks for failure of the cloned device mounts, which
is no longer true after the commit a5b8a5f9f835 ("btrfs: support
cloned-device mount capability"). So check for the non-presence the
temp-fsid feature and do not test for the failure of the cloned device
mount.
Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202310251645.5fe5495a-oliver.sang@intel.com Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Thu, 2 Nov 2023 11:28:20 +0000 (19:28 +0800)]
btrfs/219: fix _cleanup() to successful release the loop-device
When we fail with the message 'We were allowed to mount when we should
have failed,' it will fail to clean up the loop devices, making it
difficult to run further test cases or the same test case again.
So we need a 2nd loop device local variable to release it. Let's
reorganize the local variables to clean them up in the _cleanup() function.
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Anand Jain [Thu, 2 Nov 2023 11:28:18 +0000 (19:28 +0800)]
common/rc: _fs_sysfs_dname fetch fsid using btrfs tool
Currently _fs_sysfs_dname gets fsid from the findmnt command however
this command provides the metadata_uuid if the device is mounted with
temp-fsid. So instead, use btrfs filesystem show command to know the fsid.
Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
xfs/146 uses the xfs_io falloc subcommand and thus kernel fallocate
support. Ensure the support is present.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Bill O'Donnell [Fri, 1 Sep 2023 16:18:16 +0000 (11:18 -0500)]
fstests: generic/353 should accomodate other pwrite behaviors
xfs_io pwrite issues a series of block size writes, but there is no
guarantee that the resulting extent(s) will be singular or contiguous.
This behavior is acceptable, but the test is flawed in that it expects
a single extent for a pwrite.
Modify test to use actual blocksize for pwrite and reflink. Also
modify it to accommodate pwrite and reflink that produce different
mapping results.
Signed-off-by: Bill O'Donnell <bodonnel@redhat.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Tue, 24 Oct 2023 11:23:46 +0000 (12:23 +0100)]
btrfs: test snapshotting a subvolume that was just created
Test that snapshotting a new subvolume (created in the current transaction)
that has a btree with a height > 1, works and does not result in a fs
corruption.
This exercises a regression introduced in kernel 6.5 by the kernel commit:
1b53e51a4a8f ("btrfs: don't commit transaction for every subvol create")
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Amir Goldstein [Mon, 23 Oct 2023 16:32:59 +0000 (19:32 +0300)]
overlay: add test for lowerdir mount option parsing
Check parsing and display of spaces and escaped colons and commans in
lowerdir mount option.
This is a regression test for two bugs introduced in v6.5 with the
conversion to new mount api.
There is another regression of new mount api related to libmount parsing
of escaped commas, but this needs a fix in libmount - this test only
verifies the fixes in the kernel, so it uses LIBMOUNT_FORCE_MOUNT2=always
to force mount(2) and kernel pasring of the comma separated options list.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
The count of failure messages is the same as the count as the "-l 4k"
fstrim invocations. Since this is an 8k-block filesystem, the -l
parameter is clearly incorrect. The test computes random -m and -l
options.
Therefore, create helper functions to guess at the minimum and maximum
length and minlen parameters that can be used with the fstrim program.
In the inner loop of the test, make sure that our choices for -m and -l
fall within those constraints.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Thu, 26 Oct 2023 03:12:02 +0000 (20:12 -0700)]
generic/251: don't snapshot $here during a test
Zorro complained that the next patch caused him a regression:
generic/251 249s ... [failed, exit status 1]- output mismatch (see /root/git/xfstests/results//generic/251.out.bad)
--- tests/generic/251.out 2022-04-29 23:07:23.263498297 +0800
+++ /root/git/xfstests/results//generic/251.out.bad 2023-10-22 14:17:07.248059405 +0800
@@ -1,2 +1,5 @@
QA output created by 251
Running the test: done.
+5838a5839
+> aa60581221897d3d7dd60458e1cca2fa ./results/generic/251.full
+!!!Checksums has changed - Filesystem possibly corrupted!!!\n
...
(Run 'diff -u /root/git/xfstests/tests/generic/251.out /root/git/xfstests/results//generic/251.out.bad' to see the entire diff)
Ran: generic/251
Failures: generic/251
Failed 1 of 1 tests
The next patch writes some debugging information into $seqres.full,
which is a file underneat $RESULT_BASE. If the test operator does not
set RESULT_BASE, it will be set to a subdir of $here by default. Since
this test also snapshots the contents of $here before starting its loop,
any logging to $seqres.full on such a system will cause the post-copy
checksum to fail due to a mismatch.
Fix all this by copying $here to $SCRATCH_DEV and checksumming the copy
before the FITRIM stress test begins to avoid problems with $seqres.full.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Thu, 19 Oct 2023 10:06:14 +0000 (11:06 +0100)]
btrfs/298: fix failure when added device supports trim
A btrfs device add command issues a trim on the device if the device
supports trim, and then it outputs a message to stdout informing that it
performed a trim. If that happens it breaks the golden output and the
test fails like this:
btrfs/298 - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/298.out.bad)
--- tests/btrfs/298.out 2023-10-18 23:29:06.029292800 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/298.out.bad 2023-10-19 10:54:29.693210881 +0100
@@ -1,2 +1,3 @@
QA output created by 298
+Performing full device TRIM /dev/sdd (100.00GiB) ...
Silence is golden
...
(Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/298.out /home/fdmanana/git/hub/xfstests/results//btrfs/298.out.bad' to see the entire diff)
Ran: btrfs/298
Failures: btrfs/298
Failed 1 of 1 tests
Fix this by redirecting the device add's stdout to the $seqres.full file.
Any device add errors are sent to stderr, so we'll notice if errors happen
due to possible future regressions, as it will break the golden output.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Su Yue [Thu, 19 Oct 2023 01:53:56 +0000 (09:53 +0800)]
generic/245: Filter mv error message
Coreutils commit 3cb862ce5f10 ( mv: better diagnostic for 'mv dir x' failure)
was released in v9.4, changed the error message from
'mv: cannot move 'b/t' to 'a/t': Directory not empty' to
'mv: cannot overwrite 'a/t': Directory not empty' in case of
EDQUOT/EEXIST/EISDIR/EMLINK/ENOSPC/ENOTEMPTY/ETXTBSY.
The change breaks generic/245 due to the mismatched output:
generic/245 1s ... - output mismatch (see /root/xfstests-dev/results//generic/245.out.bad)
--- tests/generic/245.out 2023-10-05 11:15:21.124295738 +0800
+++ /root/xfstests-dev/results//generic/245.out.bad 2023-10-05 11:15:23.456315468 +0800
@@ -1,2 +1,2 @@
QA output created by 245
-mv: cannot move 'TEST_DIR/test-mv/ab/aa/' to 'TEST_DIR/test-mv/aa': File exists
+mv: cannot overwrite 'TEST_DIR/test-mv/aa': File exists
...
(Run 'diff -u /root/xfstests-dev/tests/generic/245.out /root/xfstests-dev/results//generic/245.out.bad' to see the entire diff)
Filter out and replace mv error messages to fix the test.
Signed-off-by: Su Yue <glass.su@suse.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 9 Oct 2023 18:18:45 +0000 (11:18 -0700)]
generic/269,xfs/051: don't drop fsstress failures to stdout
Prior to commit f55e46d629, these two tests would run fsstress until it
hit a failure -- ENOSPC in the case of generic/269, and EIO in the case
of xfs/051. These errors are expected, which was why stderr was also
redirected to /dev/null. Commit f55e46d629 removed the stderr
redirection, which has resulted in a 100% failure rate.
Fix this regression by pushing stderr stream to $seqres.full.
Fixes: f55e46d629 ("fstests: redirect fsstress' stdout to $seqres.full instead of /dev/null") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Mon, 9 Oct 2023 18:18:39 +0000 (11:18 -0700)]
generic/465: only complain about stale disk contents when racing directio
This test does a strange thing with directio -- it races a reader thread
with an appending aio writer thread and checks that the reader thread
only ever sees a (probably short) buffer containing the same contents
that are being read.
However, this has never worked correctly on XFS, which supports
concurrent readers and writers for directio. Say you already have a
file with a single written mapping A:
This implies separate bios for b and c. Both bios are issued, but c
completes first. The ioend for c will extend i_size all the way to
new_EOF. Extent b is still marked unwritten because it hasn't completed
yet.
Next, the test reader slips in and tries to read the range between the
old EOF and the new EOF. The file looks like this now:
So the reader sees "bbbbCCCCC" in the mapping, and the buffer returned
contains a range of zeroes followed by whatever was written to C.
For pagecache IO I would say that i_size should not be extended until
the extending write is fully complete, but the pagecache also
coordinates access so that reads and writes cannot conflict.
However, this is directio. Reads and writes to the storage device can
be issued and acknowledged in any order. I asked Ted and Jan about this
point, and they echoed that for directio it's expected that application
software must coordinate access themselves.
In other words, the only thing that the reader can check here is that
the filesystem is not returning stale disk contents. Amend the test so
that null bytes in the reader buffer are acceptable.
Cc: tytso@mit.edu Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
attempting to find secondary superblock...
found candidate secondary superblock...
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
+error reading superblock 1 -- seek to offset 584115421184 failed
+unable to verify superblock, continuing...
+found candidate secondary superblock...
verified secondary superblock...
writing modified primary superblock
sb root inode INO inconsistent with calculated value INO
Eventually I tracked this down to a mis-interaction between the test,
xfs_repair, and the storage device.
If the device doesn't support discard, _scratch_mkfs won't zero the
entire disk to remove old dead superblocks that might have been written
by previous tests. After we shatter the primary super, the xfs_repair
scanning code can still trip over those old supers when it goes looking
for secondary supers.
Most of the time it finds the actual AG 1 secondary super, but sometimes
it finds ghosts from previous formats. When that happens, xfs_repair
will talk quite a bit about those failed secondaries, even if it
eventually finds an acceptable secondary sb and completes the repair.
Filter out the messages about secondary supers.
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>