Darrick J. Wong [Mon, 10 Nov 2025 18:26:32 +0000 (10:26 -0800)]
generic/778: fix severe performance problems
This test takes 4800s to run, which is horrible. AFAICT it starts out
by timing how much can be written atomically to a new file in 0.2
seconds, then scales up the file size by 3x. On not very fast storage,
this can result in file_size being set to ~250MB on a 4k fsblock
filesystem. That's about 64,000 blocks.
The next thing this test does is try to create a file of that size
(250MB) of alternating written and unwritten blocks. For some reason,
it sets up this file by invoking xfs_io 64,000 times to write small
amounts of data, which takes 3+ minutes on the author's system because
exec overhead is pretty high when you do that.
As a result, one loop through the test takes almost 4 minutes. The test
loops 20 times, so it runs for 80 minutes(!!) which is a really long
time.
So the first thing we do is observe that the giant slow loop is being
run as a single thread on an empty filesystem. Most of the time the
allocator generates a mostly physically contiguous file. We could
fallocate the whole file instead of fallocating one block every other
time through the loop. This halves the setup time.
Next, we can also stuff the remaining pwrite commands into a bash array
and only invoke xfs_io once every 128x through the loop. This amortizes
the xfs_io startup time, which reduces the test loop runtime to about 20
seconds.
Finally, replace the 20x loop with a _soak_loop_running 5x loop because
5 seems like enough. Anyone who wants more can set TIME_FACTOR or
SOAK_DURATION to get more intensive testing. On my system this cuts the
runtime to 75 seconds.
Cc: fstests@vger.kernel.org # v2025.10.20 Fixes: ca954527ff9d97 ("generic: Add sudden shutdown tests for multi block atomic writes") 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, 10 Nov 2025 18:26:17 +0000 (10:26 -0800)]
common: leave any breadcrumbs when _link_out_file_named can't find the output file
_link_out_file_named is an obnoxiously complicated helper involving a
perl script embedded inside a bash subshell that does ... a lookup of
some sort involving comparing the comma-separated list in its second
argument against a comma-separated list in a config file that then maps
to an output file suffix. I don't know what it really does. The .cfg
file format is undocumented except for the perl script.
This is really irritating every time I have to touch any of these tests
with flexible golden outputs, and I frequently screw up the mapping.
The helper is not very helpful when you do this, because it doesn't even
try to tell you *which* suffix it found, let alone how it got there.
Fix this up so that the .full file gets some diagnostics, even if the
stdout text is "no qualified output".
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Zorro Lang <zlang@kernel.org>
Theodore Ts'o [Fri, 14 Nov 2025 01:02:38 +0000 (20:02 -0500)]
generic/773: fix expected output "QA output created by 1226"
The test generic/773 was apparently submitted as generic/1226, but
when it was renamed to pack the test namespace, apparently the test
output wasn't adjusted to reflect the new test name, leading to the
test failing on sytems that have devices that support atomic writes.
Fixes: 1499d4ff2365 ("generic: Add atomic write test using fio crc ...") Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Zorro Lang <zlang@kernel.org>