All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Leo Martins <loemra.dev@gmail.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com, fstests@vger.kernel.org
Subject: Re: [PATCH] generic/301: skip extent count check on btrfs
Date: Tue, 24 Mar 2026 13:49:58 -0700	[thread overview]
Message-ID: <20260324204958.GD6212@frogsfrogsfrogs> (raw)
In-Reply-To: <c56960b514baf810f2929b5e955a966d9955c468.1774383226.git.loemra.dev@gmail.com>

On Tue, Mar 24, 2026 at 01:40:00PM -0700, Leo Martins wrote:
> The 2/3 fragmentation threshold was designed for XFS's cowextsize
> mechanism and is not applicable to btrfs. After commit 0dc118b3c327
> ("btrfs: be less aggressive with metadata overcommit when we can do
> full flushing"), btrfs commits transactions more frequently during
> writeback, reducing the extent allocator's opportunity to coalesce
> adjacent CoW extents. This causes the extent count to sometimes cross
> the threshold, making the test flaky on btrfs.
> 
> Skip only the extent count assertion for btrfs while keeping the CoW
> write + remount + md5sum data integrity checks, which remain useful.
> 
> Signed-off-by: Leo Martins <loemra.dev@gmail.com>

Seems reasonable to me,
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> ---
>  tests/generic/301 | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/generic/301 b/tests/generic/301
> index 0303f25d..985d943a 100755
> --- a/tests/generic/301
> +++ b/tests/generic/301
> @@ -62,7 +62,12 @@ new_extents=$(_count_extents $testdir/file2)
>  echo "old extents: $old_extents" >> $seqres.full
>  echo "new extents: $new_extents" >> $seqres.full
>  echo "maximum extents: $internal_blks" >> $seqres.full
> -test $new_extents -lt $((internal_blks * 2 / 3)) || echo "file2 badly fragmented"
> +# btrfs CoW extent allocation depends on transaction commit frequency and
> +# metadata reservation behavior, so the 2/3 fragmentation threshold (designed
> +# for XFS cowextsize) is not applicable.
> +if [ "$FSTYP" != "btrfs" ]; then
> +	test $new_extents -lt $((internal_blks * 2 / 3)) || echo "file2 badly fragmented"
> +fi
>  
>  # success, all done
>  status=0
> -- 
> 2.52.0
> 
> 

  reply	other threads:[~2026-03-24 20:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 20:40 [PATCH] generic/301: skip extent count check on btrfs Leo Martins
2026-03-24 20:49 ` Darrick J. Wong [this message]
2026-03-24 21:07 ` Qu Wenruo
2026-03-25  5:48 ` Christoph Hellwig
2026-03-31 20:06   ` 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=20260324204958.GD6212@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=loemra.dev@gmail.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 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.