From: "Darrick J. Wong" <djwong@kernel.org>
To: Lukas Herbolt <lukas@herbolt.com>
Cc: zlang@kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 3/4] generic/{102,172,347}: Adapt test for XFS on systems with 128+CPUs + SSDs
Date: Thu, 30 Apr 2026 09:31:58 -0700 [thread overview]
Message-ID: <20260430163158.GR7739@frogsfrogsfrogs> (raw)
In-Reply-To: <20260430131317.693845-8-lukas@herbolt.com>
On Thu, Apr 30, 2026 at 03:13:20PM +0200, Lukas Herbolt wrote:
> XFS will now scale by default its log size according the amount of CPUs. This
> can significantly increase the log area and using hardcoded size of file size
> will make the test file. Using the the X percent of the free space to create
> the file will let the test proceed.
>
> For generic/102 we also have to change the 102.out as we cannot know the
> amount written data and it has to be filterred out.
>
> For generic/172 we just use the new function to calculate file big enough
> to consume most of the available space.
>
> The generic/347 will use -l concurency=0 in case it is being run on the
> XFS filesystem and mkfs.xfs already supports this option.
>
> Signed-off-by: Lukas Herbolt <lukas@herbolt.com>
> ---
> tests/generic/102 | 5 +++--
> tests/generic/102.out | 20 ++++++++++----------
> tests/generic/172 | 8 ++++----
> tests/generic/347 | 9 ++++++++-
> 4 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/tests/generic/102 b/tests/generic/102
> index daa5061bd3fe..60e651fefb5b 100755
> --- a/tests/generic/102
> +++ b/tests/generic/102
> @@ -23,12 +23,13 @@ _require_scratch
> dev_size=$((1024 * 1024 * 1024)) # 1GB filesystem
> _scratch_mkfs_sized $dev_size >>$seqres.full 2>&1
> _scratch_mount
> +file_size=`_mb_pct_of_available_space $SCRATCH_DEV 95`
>
> for ((i = 0; i < 10; i++)); do
> echo "loop $i" >>$seqres.full
>
> - $XFS_IO_PROG -f -c "pwrite -b 1m 0 800m" "$SCRATCH_MNT"/file | \
> -_filter_xfs_io | _filter_scratch
> + $XFS_IO_PROG -f -c "pwrite -b 1m 0 ${file_size}m" "$SCRATCH_MNT"/file | \
> +_filter_xfs_io_numbers | _filter_scratch
Ah, ok, so we're using 95% of the available space, not just a static
800M? That's a pretty big difference...
> rm -f "$SCRATCH_MNT"/file
> done
> diff --git a/tests/generic/102.out b/tests/generic/102.out
> index b58aa5ccc68b..647bb23abec1 100644
> --- a/tests/generic/102.out
> +++ b/tests/generic/102.out
> @@ -1,21 +1,21 @@
> QA output created by 102
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 838860800/838860800 bytes at offset 0
> +wrote XXXX/XXXX bytes at offset XXXX
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> diff --git a/tests/generic/172 b/tests/generic/172
> index b67e817b667b..06f9370f065d 100755
> --- a/tests/generic/172
> +++ b/tests/generic/172
> @@ -37,15 +37,15 @@ echo "Reformat with appropriate size"
> blksz="$(_get_block_size $testdir)"
> _scratch_unmount
>
> -file_size=$((768 * 1024 * 1024))
> fs_size=$((1024 * 1024 * 1024))
> _scratch_mkfs_sized $fs_size >> $seqres.full 2>&1
> _scratch_mount >> $seqres.full 2>&1
> rm -rf $testdir
> mkdir $testdir
> +file_size=`_mb_pct_of_available_space $SCRATCH_DEV 70`
...particularly since you replace 768/1024 with 70% here.
> echo "Create a big file and reflink it"
> -_pwrite_byte 0x61 0 $file_size $testdir/bigfile >> $seqres.full 2>&1
> +_pwrite_byte 0x61 0 ${file_size}m $testdir/bigfile >> $seqres.full 2>&1
> _cp_reflink $testdir/bigfile $testdir/clonefile
> _scratch_sync
>
> @@ -54,7 +54,7 @@ _fill_fs $fs_size $testdir/space $blksz 0 >> $seqres.full 2>&1
> _scratch_sync
>
> echo "CoW the big file"
> -out="$(_pwrite_byte 0x62 0 $file_size $testdir/bigfile 2>&1 | \
> +out="$(_pwrite_byte 0x62 0 ${file_size}m $testdir/bigfile 2>&1 | \
> _filter_xfs_io_error)"
> echo ${out} | grep -q "No space left on device" || echo "CoW should have failed with ENOSPC"
> echo ${out} >> $seqres.full 2>&1
> @@ -63,7 +63,7 @@ echo ${out}
> echo "Remount and try CoW again"
> _scratch_cycle_mount
>
> -out="$(_pwrite_byte 0x62 0 $file_size $testdir/bigfile 2>&1 | \
> +out="$(_pwrite_byte 0x62 0 ${file_size}m $testdir/bigfile 2>&1 | \
> _filter_xfs_io_error)"
> echo ${out} | grep -q "No space left on device" || echo "CoW should have failed with ENOSPC"
> echo ${out} >> $seqres.full 2>&1
> diff --git a/tests/generic/347 b/tests/generic/347
> index 5c0e3f949585..cf3cfc94c8c4 100755
> --- a/tests/generic/347
> +++ b/tests/generic/347
> @@ -14,6 +14,13 @@ BACKING_SIZE=$((500 * 1024 * 1024 / 512)) # 500M
> VIRTUAL_SIZE=$((10 * $BACKING_SIZE)) # 5000M
> GROW_SIZE=$((100 * 1024 * 1024 / 512)) # 100M
>
> +dmthin_mkfs_opts=""
> +if [ $FSTYP == "xfs" ]; then
> + if _scratch_mkfs_xfs_supported -l concurrency=0 >> $seqres.full 2>&1; then
_scratch_mkfs_supports_concurrency ?
> + dmthin_mkfs_opts="-l concurrency=0"
> + fi
> +fi
> +
> # Override the default cleanup function.
> _cleanup()
> {
> @@ -25,7 +32,7 @@ _setup_thin()
> {
> _dmthin_init $BACKING_SIZE $VIRTUAL_SIZE
> _dmthin_set_queue
> - _dmthin_mkfs
> + _dmthin_mkfs $dmthin_mkfs_opts
> _dmthin_mount
> }
>
> --
> 2.53.0
>
>
next prev parent reply other threads:[~2026-04-30 16:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 13:13 [PATCH 0/4] Fixes for mkfs.xfs with high amount of CPUs and SSDs Lukas Herbolt
2026-04-30 13:13 ` [PATCH 1/4] common/rc: Add helper to calculate percetage of free space available Lukas Herbolt
2026-04-30 16:42 ` Darrick J. Wong
2026-04-30 13:13 ` [PATCH 2/4] common/xfs: helper function to check if -l/-d/-r concurrecy flags Lukas Herbolt
2026-04-30 16:39 ` Darrick J. Wong
2026-04-30 13:13 ` [PATCH 3/4] generic/{102,172,347}: Adapt test for XFS on systems with 128+CPUs + SSDs Lukas Herbolt
2026-04-30 16:31 ` Darrick J. Wong [this message]
2026-04-30 13:13 ` [PATCH 4/4] xfs/216 xfs/217 Use default -l conccurency=0 on mkfs.xfs that supports it Lukas Herbolt
2026-04-30 16:36 ` Darrick J. Wong
2026-05-14 8:11 ` Lukas Herbolt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260430163158.GR7739@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=lukas@herbolt.com \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox