On 3/8/24 18:00, Filipe Manana wrote:
On Thu, Mar 7, 2024 at 4:46 PM Anand Jain <anand.jain@xxxxxxxxxx> wrote:
I'm also not convinced that we need this test, because the bug could
be reliably reproduced by running all existing tests or just a subset
of the tests as I reported there.
This test case was motivated by btrfs/159; and recent report;
yep, most of the lines here are taken from btrfs/159.
Ok, so it's motivated by what I reported, triggered by btrfs/159 but
only when other tests are run before it.
However, I wanted a test case in the tempfsid group which
exercises multi-node-same-physical;
Sure. It's just that we could trigger the issue simply by running all
existing tests, or just a subset as I reported before [1].
It was fully deterministic and David could reproduce it after the report too.
What surprises me is that no one noticed this before and at some stage
the faulty patch was about to be sent to Linus.
If there are no objections, I am going to add the tempfsid group to
btrfs/159 for now.
That is confusing, please don't.
btrfs/159 doesn't test tempfsid, it existed for many years before the
tempfsid feature (introduced in the 6.7 kernel),
it just happens that it triggers the issue if other fstests are run before it.
That would also be pointless because running btrfs/159 alone doesn't
trigger the bug, so running "./check -g tempfsid" wouldn't cause 159
to fail.
Between that and a new test case that is somewhat redundant, I'd
rather have the new test case with proper documentation/comments.
I have converted this test case into a generic one. Now, XFS, ext4,
and Btrfs (after a patch) match the golden output. I'll be sending
the btrfs kernel patch along with it.
Thanks, Anand
Thanks.
[1] https://lore.kernel.org/linux-btrfs/CAL3q7H5wx5rKmSzGWP7mRqaSfAY88g=35N4OBrbJB61rK0mt2w@xxxxxxxxxxxxxx/
Thanks, Anand
