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
>
prev parent 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