Darrick J. Wong [Tue, 6 Feb 2024 00:06:50 +0000 (16:06 -0800)]
common/xfs: fix _xfs_get_file_block_size when rtinherit is set and no rt section
It's possible for the sysadmin to set rtinherit on the directory tree
even if there isn't a realtime section attached to the filesystem. When
this is the case, the realtime flag is /not/ passed to new files, and
file data is written to the data device. The file allocation unit for
the file is the fs blocksize, and it is not correct to use the rt
extent.
fstests can be fooled into doing the incorrect thing if test runner puts
'-d rtinherit=1 -r extsize=28k' into MKFS_OPTIONS without configuring a
realtime device. This causes many tests to do the wrong thing because
they think they must operate on units of 28k (and not 4k). Fix this.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:50 +0000 (16:06 -0800)]
generic/331,xfs/240: support files that skip delayed allocation
The goal of this test is to ensure that log recovery finishes a copy on
write operation in the event of temporary media errors. It's important
that the test observe some sort of IO error once we switch the scratch
device to fail all IOs, but regrettably the test encoded the specific
behavior of XFS and btrfs when the test was written -- the aio write
to the page cache doesn't have to touch the disk and succeeds, and the
fdatasync flushes things to disk and hits the IO error.
However, this is not how things work on the XFS realtime device. There
is no delalloc on realtime, so the aio write allocates an unwritten
extent to stage the write. The allocation fails due to EIO, so it's the
write call that fails. Therefore, all we need to do is to detect an IO
error at any point between the write and the fdatasync call to be
satisfied that the test does what we want to do.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:47 +0000 (16:06 -0800)]
fuzzy: create missing fuzz tests for rt rmap btrees
Back when I first created the fuzz tests for the realtime rmap btree, I
forgot a couple of things. Add tests to fuzz rtrmap btree leaf records,
and node keys.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:47 +0000 (16:06 -0800)]
populate: adjust rtrmap calculations for rtgroups
Now that we've sharded the realtime volume and created per-group rmap
btrees, we need to adjust downward the size of rtrmapbt records since
the block counts are now 32-bit instead of 64-bit.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs: skip tests if formatting small filesystem fails
There are a few tests that try to exercise XFS functionality with an
unusually small (< 500MB) filesystem. Formatting can fail if the test
configuration also specifies a very large realtime device because mkfs
hits ENOSPC when allocating the realtime metadata. The test proceeds
anyway (which causes an immediate mount failure) so we might as well
skip these.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs/3{43,32}: adapt tests for rt extent size greater than 1
Both of these tests for the realtime volume can fail when the rt extent
size is larger than a single block.
332 is a read-write functionality test that encodes md5sum in the
output, so we need to skip it if $blksz isn't congruent with the extent
size, because the fcollapse call will fail.
343 is a test of the rmap btree, so the fix here is simpler -- make
$blksz the file allocation unit, and get rid of the md5sum in the
golden output.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs/341: update test for rtgroup-based rmap
Now that we're sharding the realtime volume into multiple allocation
groups, update this test to reflect the new reality. The realtime rmap
btree record and key sizes have shrunk, and we can't guarantee that a
quick file write actually hits the same rt group as the one we fuzzed,
so eliminate the file write test since we're really only curious if
xfs_repair will fix the problem.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:46 +0000 (16:06 -0800)]
xfs: fix various problems with fsmap detecting the data device
Various tests of realtime rmap functionality assumed that the data
device could be picked out from the GETFSMAP output by looking for
static fs metadata. This is no longer true, since rtgroups have a
static superblock header at the start, so update these tests.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:45 +0000 (16:06 -0800)]
xfs/122: update for rtgroups-based realtime rmap btrees
Now that we've redesigned realtime rmap to require that the rt section
be sharded into allocation groups of no more than 2^31 blocks, we've
reduced the size of the ondisk structures and therefore need to update
this test.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:45 +0000 (16:06 -0800)]
fuzz: for fuzzing the rtrmapbt, find the path to the rt rmap btree file
The fs population code creates a realtime rmap btree in /some/ realtime
group with at least two levels. This rmapbt file isn't necessarily the
one for group 0, so we need to find it programmatically.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:44 +0000 (16:06 -0800)]
xfs: fix tests that try to access the realtime rmap inode
The realtime rmap tests were added to fstests a long time ago. Since
they were added, we decided to create a metadata file directory
structure instead of adding more fields to the superblock. Therefore,
fix all the tests that try to access these paths.
While we're at it, fix xfs/409 to run the *online* scrub program like
it's supposed to. xfs/408 is the fuzzer for xfs_repair testing.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:43 +0000 (16:06 -0800)]
common/xfs: capture realtime devices during metadump/mdrestore
If xfs_metadump supports the -r switch to capture the contents of
realtime devices and there is a realtime device, add the option to the
command line to enable preservation.
Similarly, if the dump file could restore to an external scratch rtdev,
pass the -r option to mdrestore so that we can restore rtdev contents.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:42 +0000 (16:06 -0800)]
xfs/449: update test to know about xfs_db -R
The realtime groups feature added a -R flag to xfs_db so that users can
pass in the realtime device. Since we've now modified the
_scratch_xfs_db to use this facility, we can update the test to do exact
comparisons of the xfs_db info command against the mkfs output.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:42 +0000 (16:06 -0800)]
xfs/185: update for rtgroups
This old test is a bit too fixated on exact rt allocator behavior. With
rtgroups enabled, we can end up with one large contiguous region that's
split into multiple bmbt mappings to avoid crossing rtgroup boundaries.
The realtime superblock throws another twist into the mix because the
first rtx will always be in use, which can shift the start of the
physical space mappings by up to 1 rtx.
Also fix a bug where we'd try to fallocate the total number of rtx,
whereas we should be asking for the number of free rtx to avoid ENOSPC
errors.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:41 +0000 (16:06 -0800)]
punch-alternating: detect xfs realtime files with large allocation units
For files on the XFS realtime volume, it's possible that the file
allocation unit (aka the minimum size we have to punch to deallocate
file blocks) could be greater than a single fs block. This utility
assumed that it's always possible to punch a single fs block, but for
these types of files, all that does is zeroes the page cache. While
that's what most *user applications* want, fstests uses punching to
fragment file mapping metadata and/or fragment free space, so adapt this
test for that purpose by detecting realtime files.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:41 +0000 (16:06 -0800)]
common/populate: use metadump v2 format by default for fs metadata snapshots
When we're snapshotting filesystem metadata after creating a populated
filesystem, force the creation of metadump v2 files by default to
exercise the new format, since xfs_metadump continues to use the v1
format unless told otherwise.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:40 +0000 (16:06 -0800)]
common/ext4: reformat external logs during mdrestore operations
The e2image file format doesn't support the capture of external log
devices, which means that mdrestore ought to reformat the external log
to get the restored filesystem to work again. The common/populate code
could already do this, so push it to the common ext4 helper.
While we're at it, fix the uncareful usage of SCRATCH_LOGDEV in the
populate code.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:40 +0000 (16:06 -0800)]
common/populate: refactor caching of metadumps to a helper
Hoist out of _scratch_populate_cached all the code that we use to save a
metadump of the populated filesystem. We're going to make this more
involved for XFS in the next few patches so that we can take advantage
of the new support for external devices in metadump/mdrestore.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:39 +0000 (16:06 -0800)]
xfs/509: adjust inumbers accounting for metadata directories
The INUMBERS ioctl exports data from the inode btree directly -- the
number of inodes it reports is taken from ir_freemask and includes all
the files in the metadata directory tree. BULKSTAT, on the other hand,
only reports non-metadata files. When metadir is enabled, this will
(eventually) cause a discrepancy in the inode counts that is large
enough to exceed the tolerances, thereby causing a test failure.
Correct this by counting the files in the metadata directory and
subtracting that from the INUMBERS totals.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:38 +0000 (16:06 -0800)]
xfs/{050,144,153,299,330}: update quota reports to handle metadir trees
Prior to the new metadir feature in XFS, the rtbitmap and rtsummary
files were included in icount, though their bcount contribution is zero
due to rt and quota not being supported together. With the new metadir
feature in XFS, no files in the metadata directory tree are counted in
quota.
Hence we must adjust the icount of any quota report down by two to avoid
breaking golden outputs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:38 +0000 (16:06 -0800)]
common/repair: patch up repair sb inode value complaints
Now that we've refactored xfs_repair to be more consistent in how it
reports unexpected superblock inode pointer values, we have to fix up
the fstests repair filters to emulate the old golden output.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:38 +0000 (16:06 -0800)]
xfs/{030,033,178}: forcibly disable metadata directory trees
The golden output for thests tests encode the xfs_repair output when we
fuzz various parts of the filesystem. With metadata directory trees
enabled, however, the golden output changes dramatically to reflect
reconstruction of the metadata directory tree.
To avoid regressions, add a helper to force metadata directories off via
MKFS_OPTIONS.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:37 +0000 (16:06 -0800)]
various: fix finding metadata inode numbers when metadir is enabled
There are a number of tests that use xfs_db to examine the contents of
metadata inodes to check correct functioning. The logic is scattered
everywhere and won't work with metadata directory trees, so make a
shared helper to find these inodes.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:33 +0000 (16:06 -0800)]
xfs/004: fix column extraction code
Now that the xfs_db freesp command prints a CDF of the free space
histograms, fix the pct column extraction code to handle the two
new columns by <cough> using awk.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Tue, 6 Feb 2024 00:06:33 +0000 (16:06 -0800)]
generic/453: check xfs_scrub detection of confusing job offers
Earlier this year, ESET revealed that Linux users had been tricked into
opening executables containing malware payloads. The trickery came in
the form of a malicious zip file containing a filename with the string
"job offer․pdf". Note that the filename does *not* denote a real pdf
file, since the last four codepoints in the file name are "ONE DOT
LEADER", p, d, and f. Not period (ok, FULL STOP), p, d, f like you'd
normally expect.
Now that xfs_scrub can look for codepoints that could be confused with a
period followed by alphanumerics, let's make sure it actually works.
Darrick J. Wong [Tue, 6 Feb 2024 00:06:32 +0000 (16:06 -0800)]
generic/453: test confusable name detection with 32-bit unicode codepoints
Test the confusable name detection when there are 32-bit unicode
sequences in use. In other words, emoji. Change the xfs_scrub test to
dump the output to a file instead of passing huge echo commands around.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Darrick J. Wong [Wed, 24 Jul 2024 17:43:48 +0000 (10:43 -0700)]
xfs: remove all traces of xfs_check
xfsprogs stopped shipping xfs_check (the wrapper script) in May 2014.
It's now been over a decade since it went away, and its replacements
(xfs_repair and xfs_scrub) now detect a superset of the problems that
check can find.
There is no longer any point in invoking xfs_check, so let's remove it
from fstests completely.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong [Fri, 26 Jul 2024 16:51:07 +0000 (09:51 -0700)]
generic/754: fix _fixed_by tags
This test requires an xfs_repair patch, so note that in the test. Also
update the kernel git hash since we now have one.
Reported-by: maxj.fnst@fujitsu.com 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>
Christoph Hellwig [Mon, 15 Jul 2024 06:24:53 +0000 (08:24 +0200)]
xfs/011: support byte-based grant heads are stored in bytes now
New kernels where reservation grant track the actual reservation space
consumed in bytes instead of LSNs in cycle/block tuples export different
sysfs files for this information.
Adapt the test to detect which version is exported, and simply check
for a near-zero reservation space consumption for the byte based version.
Based on work from Dave Chinner.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
f2fs: test for race condition in between atomic_write and dio
Test that we will simulate sqlite atomic write logic w/ below steps:
1. create a regular file, and initialize it w/ 0xff data
2. start transaction (via F2FS_IOC_START_ATOMIC_WRITE) on it
3. write transaction data
4. trigger direct read/write IO to check whether it fails or not
5. commit and end the transaction (via F2FS_IOC_COMMIT_ATOMIC_WRITE)
This is a regression test to check handling of race condition in
between atomic_write and direct IO.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
f2fs: test for race condition in between atomic_write and gc
Test that we will simulate sqlite atomic write logic w/ below steps:
1. create a regular file, and initialize it w/ 0xff data
2. start transaction (via F2FS_IOC_START_ATOMIC_WRITE) on it
3. write transaction data
4. trigger foreground GC to migrate data block of the file
5. commit and end the transaction
6. check consistency of transaction
This is a regression test to check handling of race condition in
between atomic_write and GC.
Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Daeho Jeong <daehojeong@google.com> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Wed, 24 Jul 2024 13:58:52 +0000 (14:58 +0100)]
btrfs: properly shutdown subvolume stress worker to avoid umount failures
When killing a test that is using the subvolume stress worker, we may end
up in a situation where we end up leaving a subvolume mounted which makes
the shutdown sequence fail. Example when killing a script that keeps
running fstests in a loop:
SCRATCH_DEV=/dev/sdc is mounted but not on SCRATCH_MNT=/home/fdmanana/btrfs-tests/scratch_1 - aborting
Already mounted result:
/dev/sdc /home/fdmanana/btrfs-tests/scratch_1 /dev/sdc /home/fdmanana/btrfs-tests/dev/065.mnt
grep: results/btrfs/065.out.bad: No such file or directory
Error iteration 134, total errors 2, leaks 0
'results/btrfs/065.full' -> '/home/fdmanana/failures/btrfs_065/134/065.full'
Running 'mount' to see what's going on:
$ mount
(...)
/dev/sdb on /home/fdmanana/btrfs-tests/dev type btrfs (rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/)
/dev/sdc on /home/fdmanana/btrfs-tests/scratch_1 type btrfs (rw,relatime,discard=async,space_cache=v2,subvolid=5,subvol=/)
/dev/sdc on /home/fdmanana/btrfs-tests/dev/065.mnt type btrfs (rw,relatime,discard=async,space_cache=v2,subvolid=2627,subvol=/subvol_3395330)
Then this makes the next attempt to run a test (./check) always fail due
to the extra mount of the subvolume, requiring one to manually umount the
subvolume before running fstests again.
So update _btrfs_kill_stress_subvolume_pid() to also unmount the subvolume.
fstests: btrfs/012: fix a false alert due to socket/pipe files
[BUG]
On my Archlinux VM, the test btrfs/012 always fail with the following
output diff:
QA output created by 012
+File /etc/pacman.d/gnupg/S.dirmngr is a socket while file /mnt/scratch/etc/pacman.d/gnupg/S.dirmngr is a socket
+File /etc/pacman.d/gnupg/S.gpg-agent is a socket while file /mnt/scratch/etc/pacman.d/gnupg/S.gpg-agent is a socket
+File /etc/pacman.d/gnupg/S.gpg-agent.browser is a socket while file /mnt/scratch/etc/pacman.d/gnupg/S.gpg-agent.browser is a socket
+File /etc/pacman.d/gnupg/S.gpg-agent.extra is a socket while file /mnt/scratch/etc/pacman.d/gnupg/S.gpg-agent.extra is a socket
+File /etc/pacman.d/gnupg/S.gpg-agent.ssh is a socket while file /mnt/scratch/etc/pacman.d/gnupg/S.gpg-agent.ssh is a socket
+File /etc/pacman.d/gnupg/S.keyboxd is a socket while file /mnt/scratch/etc/pacman.d/gnupg/S.keyboxd is a socket
...
[CAUSE]
It's a false alerts.
When diff hits two files which are not directory/softlink/regular files
(aka, socket/pipe/char/block files), they are all treated as
non-comparable.
In that case, diff would just do the above message.
And with Archlinux, pacman (the package manager) maintains its gpg
directory inside "/etc/pacman.d/gnupg", and the test case uses
"/etc" as the source directory to populate the target ext4 fs.
And the socket files inside "/etc/pacman.d/gnupg" is causing the false
alerts.
[FIX]
- Use fsstress to populate the fs
That covers all kind of operations, including creating special files.
And fsstress is very reproducible, with the seed saved to the full
log, it's much easier to reproduce than using the distro dependent
"/etc/" directory.
- Use fssum to save the digest and later verify the contents
It does not only verify the contents but also other things like
timestamps/xattrs/uid/gid/mode/etc.
And it's more comprehensive than the content oriented diff tool.
Filipe Manana [Fri, 28 Jun 2024 17:04:49 +0000 (18:04 +0100)]
btrfs/081: wait for reader process to exit before cycle mounting
We send a kill signal to the reader process, check the md5sum of the
files and then cycle mount the scratch device. Most of the time the
reader process has already terminated before we attempt the cycle mount,
but sometimes it may still be alive in which case the cat command
executed by the reader process may fail because the scratch fs was
unmounted and the target file doesn't exist. This makes the cat command
print an error message and the test fail like this:
Verifying file digests after cloning 14968c092c68e32fa35e776392d14523 SCRATCH_MNT/foo 14968c092c68e32fa35e776392d14523 SCRATCH_MNT/bar
+cat: /opt/scratch/bar: No such file or directory
+cat: /opt/scratch/bar: No such file or directory
+cat: /opt/scratch/bar: No such file or directory
+cat: /opt/scratch/bar: No such file or directory
...
(Run diff -u /opt/xfstests/tests/btrfs/081.out
Fix this by making the test wait for the reader to terminate after
sending it the kill signal.
Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
fstests: btrfs/029: add fixes for the kernel behavior change
Since fstests commit 866948e00073 ("btrfs/029: change the cross vfsmount
reflink test"), the test case will fail for older kernels (e.g. 5.14
kernels from SLE).
The failure is a false alert, but it would still take some time to
figure it out.
So add the fixes tag to make it more clear that it's a kernel behavior
change.
Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
Filipe Manana [Fri, 12 Jul 2024 09:54:24 +0000 (10:54 +0100)]
btrfs: fix _require_btrfs_send_version to detect btrfs-progs support
Commit 199d0a992536df3702a0c4843d2a449d54f399c2 ("common/btrfs: introduce
_require_btrfs_send_version") turned _require_btrfs_send_v2 into a generic
helper to detect support for any send stream version, however it's only
working for detecting kernel support, it misses detecting the support from
btrfs-progs - it always checks only that it supports v2 (the send command
supports the --compressed-data option).
Fix that by verifying that btrfs-progs supports the requested version.
Boris Burkov [Tue, 9 Jul 2024 17:51:04 +0000 (10:51 -0700)]
btrfs: add test for subvolid reuse with squota
Squotas are likely to leave qgroups that outlive deleted subvolids.
Before the kernel patch 2b8aa78cf127 ("btrfs: qgroup: fix qgroup id collision across mounts")
this would lead to a repeated subvolid which would collide on an
existing qgroup id and error out with EEXIST. In snapshot creation, this
would lead to a read only fs.
Add a test which exercises the path that could create duplicate
subvolids but with squotas enabled, which should avoid the trap.
Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Zorro Lang <zlang@kernel.org>
[zlang: Remove _supported_fs line]
Johannes Thumshirn [Mon, 1 Jul 2024 08:01:09 +0000 (10:01 +0200)]
btrfs: update golden output of RST test cases
Starting with kernel patch "btrfs: remove raid-stripe-tree
encoding field from stripe_extent" and btrfs-progs commit 7c549b5f7cc0 ("btrfs-progs: remove raid stripe encoding"), the on-disk
format of the raid stripe tree got changed.
As the feature is still experimental and not to be used in production, it
is OK to do a on-disk format change.
Update the golden output of the RAID stripe tree test cases after the
on-disk format and print format changes.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Anand Jain <anand.jain@oracle.com>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:37 +0000 (14:10 +0200)]
remove spurious _supported_fs calls
Remove _supported_fs calls for generic in the generic directory
or for $FSTYP in the $FSTYP directory.
This leaves us with the negative checks, and the overloaded ext4
directory where some tests can also be run for ext2 and ext3.
While at it also remove the pointless "real QA test starts here"
usually placed right next to it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:36 +0000 (14:10 +0200)]
generic/746: clean up fs support
Use a single case statement for fs-specific options and to check if
this test is supported at all.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:35 +0000 (14:10 +0200)]
generic/745: rework support fs checking
To prepare for deprecating _supported_fs use a case statement and
_notrun.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:34 +0000 (14:10 +0200)]
generic/740: enable by default
Instead of limiting this test to a few file systems, opt out the
file systems supported in common/rc that don't support overwrite
checking at all, and those like extN that support it, but only when
run interactively.
Also remove support for really old mkfs.btrfs versions that lack
the overwrite check.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:33 +0000 (14:10 +0200)]
generic/740: skip jffs2 as foreign fs earlier
Commit a633d252e3c4 ("shared/032: add options for jffs2") added a
check to skip checking the overwrite of jffs2, but only after
adding specific mkfs options for it and zeroing part of the device.
Switch to skipping it earlier in a more obvious place.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:32 +0000 (14:10 +0200)]
generic/740: pass the --quick option to mkfs.ntfs
Without --quick mkfs.ntfs will zero the entire device, which can take
a very long time.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:31 +0000 (14:10 +0200)]
generic/740: clean up handling of mkfs options
Use a single case statement instead of lots of conditionals.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Christoph Hellwig [Sun, 23 Jun 2024 12:10:30 +0000 (14:10 +0200)]
remove support for ext4dev
ext4dev is a long deprecated alias for ext4 that was used during early
ext4 development. Drop support for it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Long Li [Fri, 12 Jul 2024 06:47:16 +0000 (14:47 +0800)]
xfs/242: fix test failure due to incorrect filtering in _filter_bmap
I got a failure in xfs/242 as follows, it can be easily reproduced
when I run xfs/242 as a cyclic test.
13. data -> unwritten -> data
0: [0..127]: data
-1: [128..511]: unwritten
-2: [512..639]: data
+1: [128..639]: unwritten
The root cause, as Dave pointed out in previous email [1], is that
_filter_bmap may incorrectly match the AG-OFFSET in column 5 for datadev
files. On the other hand, _filter_bmap missing a "next" to jump out when
it matches "data" in the 5th column, otherwise it might print the result
twice. The issue was introduced by commit 7d5d3f77154e ("xfs/242: fix
_filter_bmap for xfs_io bmap that does rt file properly"). The failure
disappeared when I retest xfs/242 by reverted commit 7d5d3f77154e.
Fix it by matching the 7th column first and then the 5th column in
_filter_bmap, because the rtdev file only has 5 columns in the `bmap -vp`
output.
Long Li [Fri, 12 Jul 2024 06:47:15 +0000 (14:47 +0800)]
xfs/016: fix test fail when head equal to near_end_min
xfs/016 checks for corruption in the log when it wraps. It looks for a log
head that is at or above the minimum log size. If the final position of
the log head equals near_end_min, the test will fail. Under these
conditions, we should let the test continue.
Signed-off-by: Long Li <leo.lilong@huawei.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Zorro Lang <zlang@kernel.org>
Darrick J. Wong [Wed, 3 Jul 2024 21:36:05 +0000 (14:36 -0700)]
xfs/444: fix agfl reset warning detection for small log buffers
Collectively, the ten subtests in xfs/444 can generate a lot of kernel
log data. If the amount of log data is enough to overflow the kernel
log buffers, the AGFL reset warning generated by fix_start and fix_wrap
might have been overwritten by subsequent log data. Fix this by
checking for the reset warning after each test and only complaining if
at the end if we have /never/ seen the warning.
Found by running on a kernel configured with CONFIG_LOG_BUF_SHIFT=14
(16K). This happened to be a Raspberry Pi, but in principle this can
happen to anyone. I'd never noticed this before because x86 helpfully
sets it to 17 (128K) by default.
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, 20 Jun 2024 21:01:06 +0000 (14:01 -0700)]
generic: test creating and removing symlink xattrs
This began as a regression test for the issues identified in "xfs: allow
symlinks with short remote targets". To summarize, the kernel XFS code
does not convert a remote symlink back to a shortform symlink after
deleting the attr fork. Recent attempts to tighten validation have
flagged this incorrectly, so we need a regression test to focus on this
dusty corner of the codebase.
However, there's nothing in here that's xfs-specific so it's a generic
test.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Dave Chinner [Thu, 20 Jun 2024 21:00:50 +0000 (14:00 -0700)]
xfs/348: partially revert dbcc549317 ("xfs/348: golden output is not correct")
In kernel commit 1eb70f54c445f ("xfs: validate inode fork size against
fork format"), we incorrectly started flagging as corrupt symlinks with
short targets that would fit in the inode core but are remote. The
kernel has historically written out symlinks this way and read them back
in, so we're fixing that.
The 1eb70 change came with change dbcc to fstests to adjust the golden
output; since we're adjusting the kernel back to old behavior, we need
to adjust the test too.
Fixes: dbcc549317 ("xfs/348: golden output is not correct") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
projects / users / hch / xfstests-dev.git / log