FS/XFS testing framework
 help / color / mirror / Atom feed
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
> 
> 

  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