public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Hans Holmberg <Hans.Holmberg@wdc.com>
Cc: "zlang@redhat.com" <zlang@redhat.com>, hch <hch@lst.de>,
	"fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH 2/2] xfs/157,xfs/547,xfs/548: switch to using _scratch_mkfs_sized
Date: Tue, 8 Oct 2024 10:11:38 -0700	[thread overview]
Message-ID: <20241008171138.GJ21840@frogsfrogsfrogs> (raw)
In-Reply-To: <20241008105055.11928-3-hans.holmberg@wdc.com>

On Tue, Oct 08, 2024 at 10:52:04AM +0000, Hans Holmberg wrote:
> From: Hans Holmberg <Hans.Holmberg@wdc.com>
> 
> These test cases specify small -d sizes which combined with a rt dev of
> unrestricted size and the rtrmap feature can cause mkfs to fail with
> error:
> 
> mkfs.xfs: cannot handle expansion of realtime rmap btree; need <x> free
> blocks, have <y>
> 
> This is due to that the -d size is not big enough to support the
> metadata space allocation required for the rt groups.
> 
> Switch to use _scratch_mkfs_sized that sets up the -r size parameter
> to avoid this. If -r size=x and -d size=x we will not risk running
> out of space on the ddev as the metadata size is just a fraction of
> the rt data size.
> 
> Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  tests/xfs/157 | 12 ++++++++----
>  tests/xfs/547 |  4 +++-
>  tests/xfs/548 |  2 +-
>  3 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/tests/xfs/157 b/tests/xfs/157
> index 79d45ac2bb34..9b5badbaeb3c 100755
> --- a/tests/xfs/157
> +++ b/tests/xfs/157
> @@ -34,18 +34,21 @@ _require_test
>  _require_scratch_nocheck
>  _require_command "$XFS_ADMIN_PROG" "xfs_admin"
>  
> +
>  # Create some fake sparse files for testing external devices and whatnot
> +fs_size=$((500 * 1024 * 1024))
> +
>  fake_datafile=$TEST_DIR/$seq.scratch.data
>  rm -f $fake_datafile
> -truncate -s 500m $fake_datafile
> +truncate -s $fs_size $fake_datafile
>  
>  fake_logfile=$TEST_DIR/$seq.scratch.log
>  rm -f $fake_logfile
> -truncate -s 500m $fake_logfile
> +truncate -s $fs_size $fake_logfile
>  
>  fake_rtfile=$TEST_DIR/$seq.scratch.rt
>  rm -f $fake_rtfile
> -truncate -s 500m $fake_rtfile
> +truncate -s $fs_size $fake_rtfile
>  
>  # Save the original variables
>  orig_ddev=$SCRATCH_DEV
> @@ -63,7 +66,8 @@ scenario() {
>  }
>  
>  check_label() {
> -	_scratch_mkfs -L oldlabel >> $seqres.full
> +	MKFS_OPTIONS="-L oldlabel $MKFS_OPTIONS" _scratch_mkfs_sized $fs_size \
> +		>> $seqres.full

I was surprised that this was necessary until I remembered that this
test checks various *combinations* of block devices and 500M files.
The block device can be quite large, so that's why you want
_scratch_mkfs_sized to force the size of both sections to 500M.
Heh, oops.  My bad, I should have caught that. :(

>  	_scratch_xfs_db -c label
>  	_scratch_xfs_admin -L newlabel "$@" >> $seqres.full
>  	_scratch_xfs_db -c label
> diff --git a/tests/xfs/547 b/tests/xfs/547
> index eada4aadc27f..ffac546be4cd 100755
> --- a/tests/xfs/547
> +++ b/tests/xfs/547
> @@ -24,10 +24,12 @@ _require_xfs_db_command path
>  _require_test_program "punch-alternating"
>  _require_xfs_io_error_injection "bmap_alloc_minlen_extent"
>  
> +fs_size=$((512 * 1024 * 1024))
> +
>  for nrext64 in 0 1; do
>  	echo "* Verify extent counter fields with nrext64=${nrext64} option"
>  
> -	_scratch_mkfs -i nrext64=${nrext64} -d size=$((512 * 1024 * 1024)) \
> +	MKFS_OPTIONS="-i nrext64=${nrext64} $MKFS_OPTIONS" _scratch_mkfs_sized $fs_size \
>  		      >> $seqres.full
>  	_scratch_mount >> $seqres.full
>  
> diff --git a/tests/xfs/548 b/tests/xfs/548
> index f0b58563e64d..af72885a9c6e 100755
> --- a/tests/xfs/548
> +++ b/tests/xfs/548
> @@ -24,7 +24,7 @@ _require_xfs_db_command path
>  _require_test_program "punch-alternating"
>  _require_xfs_io_error_injection "bmap_alloc_minlen_extent"
>  
> -_scratch_mkfs -d size=$((512 * 1024 * 1024)) >> $seqres.full
> +_scratch_mkfs_sized $((512 * 1024 * 1024)) >> $seqres.full

These other two are pretty self evident so
Reviewed-by: Darrick J. Wong <djwong@kernel.org>

--D

>  _scratch_mount >> $seqres.full
>  
>  bsize=$(_get_file_block_size $SCRATCH_MNT)
> -- 
> 2.34.1
> 

  reply	other threads:[~2024-10-08 17:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08 10:52 [PATCH 0/2] _scratch_mkfs_sized fixes for xfs rt devices Hans Holmberg
2024-10-08 10:52 ` [PATCH 2/2] xfs/157,xfs/547,xfs/548: switch to using _scratch_mkfs_sized Hans Holmberg
2024-10-08 17:11   ` Darrick J. Wong [this message]
2024-10-09  6:45     ` Hans Holmberg
2024-10-10  6:57   ` Zorro Lang
2024-10-08 10:52 ` [PATCH 1/2] common: make rt_ops local in _try_scratch_mkfs_sized Hans Holmberg
2024-10-08 11:34   ` hch
2024-10-08 17:02   ` Darrick J. Wong
2024-10-10  6:58   ` Zorro Lang

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=20241008171138.GJ21840@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=Hans.Holmberg@wdc.com \
    --cc=fstests@vger.kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /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