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. Thanks. [1] https://lore.kernel.org/linux-btrfs/CAL3q7H5wx5rKmSzGWP7mRqaSfAY88g=35N4OBrbJB61rK0mt2w@xxxxxxxxxxxxxx/ > > Thanks, Anand
