Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@redhat.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH] xfs/107: fix formatting failures
Date: Fri, 21 Jan 2022 10:41:11 +0800	[thread overview]
Message-ID: <20220121024111.5q5yebvml2x4ur2u@zlang-mailbox> (raw)
In-Reply-To: <20220120004944.GD13514@magnolia>

On Wed, Jan 19, 2022 at 04:49:44PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Zorro Lang reported that the _scratch_mkfs_sized call in the new xfs/107
> fstest sometimes fails on more exotic storage due to insufficient log
> size on account of raid stripes, etc.   These are side effects of the
> filesystem being too small.
> 
> Change the filesystem size to 256M to avoid these problems, and change
> the allocstale parameters to use the same file size (16M) as before.
> Given that ALLOCSP produces stale disk contents pretty quickly this
> shouldn't affect the test runtime too much.
> 
> Reported-by: Zorro Lang <zlang@redhat.com>
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---

Oh, I didn't notice that the xfs/107 has been merged :-P
This patch is good to me, and it fixes two "data/log space too small"
issues on my side.

Reviewed-by: Zorro Lang <zlang@redhat.com>

>  tests/xfs/107 |   10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/xfs/107 b/tests/xfs/107
> index 6034dbc2..577094b2 100755
> --- a/tests/xfs/107
> +++ b/tests/xfs/107
> @@ -22,7 +22,10 @@ _require_test
>  _require_scratch
>  _require_test_program allocstale
>  
> -size_mb=32
> +# Create a 256MB filesystem to avoid running into mkfs problems with too-small
> +# filesystems.
> +size_mb=256
> +
>  # Write a known pattern to the disk so that we can detect stale disk blocks
>  # being mapped into the file.  In the test author's experience, the bug will
>  # reproduce within the first 500KB's worth of ALLOCSP calls, so running up
> @@ -39,9 +42,10 @@ _scratch_mount
>  _xfs_force_bdev data $SCRATCH_MNT
>  testfile=$SCRATCH_MNT/a
>  
> -# Allow the test program to expand the file to consume half the free space.
> +# Allow the test program to expand the file to 32MB.  If we can't find any
> +# stale blocks at that point, the kernel has probably been patched.
>  blksz=$(_get_file_block_size $SCRATCH_MNT)
> -iterations=$(( (size_mb / 2) * 1048576 / blksz))
> +iterations=$(( (size_mb / 16) * 1048576 / blksz))
>  echo "Setting up $iterations runs for block size $blksz" >> $seqres.full
>  
>  # Run reproducer program and dump file contents if we see stale data.  Full
> 


      reply	other threads:[~2022-01-21  2:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-20  0:49 [PATCH] xfs/107: fix formatting failures Darrick J. Wong
2022-01-21  2:41 ` Zorro Lang [this message]

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=20220121024111.5q5yebvml2x4ur2u@zlang-mailbox \
    --to=zlang@redhat.com \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.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