Hi,



generic/301 has become flaky on btrfs after commit 0dc118b3c327 ("btrfs:

be less aggressive with metadata overcommit when we can do full

flushing") which landed in btrfs/for-next. Out of 30 runs, 8 fail with:



    +file2 badly fragmented



I bisected this to the above commit, which reduces the metadata

overcommit limit from 1/8th to 1/64th of available space for

full-flushing contexts. This is a legitimate fix for -ENOSPC transaction

aborts on small filesystems, but as a side effect it causes more

frequent transaction commits during writeback. The reduced batching

means the extent allocator has less opportunity to coalesce adjacent CoW

extents, resulting in higher extent counts that sometimes cross the

test's threshold.



The fragmentation check in question is:



    test $new_extents -lt $((internal_blks * 2 / 3)) || echo "file2 badly fragmented"



The 2/3 threshold was introduced in 9184ca155d7c ("xfs: test

fragmentation characteristics of copy-on-write") as part of a series

testing XFS's CoW extent size hint (cowextsize) mechanism. For btrfs,

this threshold is arbitrary — btrfs doesn't have XFS's cowextsize hint,

and its CoW extent allocation depends on factors like transaction commit

frequency and metadata reservation behavior, which is exactly what the

overcommit commit changed.



I see two possible fixes and would appreciate input on which is

preferred:



Option A: _notrun for btrfs

----------------------------



Skip the entire test since the fragmentation threshold is not applicable

to btrfs:



    test $FSTYP = "btrfs" && \

        _notrun "CoW fragmentation threshold not applicable to btrfs"



Option B: Skip only the extent count assertion for btrfs

---------------------------------------------------------



Keep the CoW + data integrity portion of the test (the md5sum checks

after random CoW writes and remount are still useful) and only skip the

fragmentation assertion:



    if [ "$FSTYP" != "btrfs" ]; then

        test $new_extents -lt $((internal_blks * 2 / 3)) || \

            echo "file2 badly fragmented"

    fi



I lean towards option B since the CoW write + remount + md5sum

verification is still a reasonable smoke test, but option A is cleaner

if the consensus is that this test isn't adding value for btrfs.



Thoughts?



Thanks,

Leo Martins