All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/347: Fix sporadic test failures
Date: Mon, 3 Aug 2026 16:27:15 +0800	[thread overview]
Message-ID: <anBNLS4JmtT8GHGu@zlang-mailbox> (raw)
In-Reply-To: <20260730151817.4120874-1-jack@suse.cz>

On Thu, Jul 30, 2026 at 05:18:17PM +0200, Jan Kara wrote:
> generic/347 was occasionally failing on ext4 in our QA due to ext4
> aborting its journal when the filesystem on thinp device was overfilled.
> I have tracked the problem down to journal checkpointing failing to
> write a metadata block to its final location due to ENOSPC failure from
> the thinp device. Modify the test to first preallocate blocks for the
> files and remount the filesystem which practically makes sure all
> involved metadata blocks were written and so their further modifications
> will not fail.
> 
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
>  tests/generic/347 | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/generic/347 b/tests/generic/347
> index 06df0cf9eddc..56538c160392 100755
> --- a/tests/generic/347
> +++ b/tests/generic/347
> @@ -38,7 +38,17 @@ _setup_thin()
>  
>  _workout()
>  {
> -	# Overfill it by a bit
> +	# Preallocate space to avoid failure for metadata writeback
> +	for I in `seq 1 500`; do
> +		$XFS_IO_PROG -f -c "falloc 0 1M" $SCRATCH_MNT/file$I &>/dev/null

Hi Jan,

Thanks for this fix! Adding fallocate introduces an extra dependency via
_require_xfs_io_command "falloc", which will limit some filesystems can
run this test.

Additionally, since the underlying storage is a thinp device, I doubt
`falloc 0 1M` actually triggers physical block allocation on the thin
pool (correct me if I'm wrong). If so, I suspect this 1M * 500 preallocation
might exhaust the 500M BACKING_SIZE prematurely (along with file system
metadata overhead), similar to the pwrite loop below.

Do you think changing it to something smaller, like fallocate 0 64k, would
be better to populate the metadata structures without prematurely running
out of thin pool space?

Thanks,
Zorro

> +	done
> +
> +	# Unmount and check the device to make sure all metadata is written
> +	_dmthin_check_fs
> +	_dmthin_mount
> +
> +	# Write the data blocks to force thinp space allocation.
> +	# Overfill it by a bit.
>  	for I in `seq 1 500`; do
>  		$XFS_IO_PROG -f -c "pwrite -W 0 1M" $SCRATCH_MNT/file$I &>/dev/null
>  	done
> -- 
> 2.51.0
> 

  reply	other threads:[~2026-08-03  8:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 15:18 [PATCH] generic/347: Fix sporadic test failures Jan Kara
2026-08-03  8:27 ` Zorro Lang [this message]
2026-08-03 11:20   ` Jan Kara
2026-08-04 10:12     ` 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=anBNLS4JmtT8GHGu@zlang-mailbox \
    --to=zlang@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=jack@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.