On Thu, May 09, 2024 at 07:43:47AM +0200, hch@xxxxxx wrote: > [really annoying multi-level full quote snipped] > > On Wed, May 08, 2024 at 04:51:35PM +0800, Zorro Lang wrote: > > I remembered you metioned btrfs fails on this test, and I can reproduce it > > on btrfs [1] with general disk. Have you figured out the reason? I don't > > want to give btrfs a test failure suddently without a proper explanation :) > > If it's a case issue, better to fix it for btrfs. > > As a rule of thumb, what do we about generally useful tests that fail > on a fs due to fs bugs? Not adding the test seems a bit counter productive. > Do we need a > > _expected_failure $FSTYP > > helper to annotate them instead of blocking the test? Hmm, what kind of situation is this _expected_failure for? For now we have two methods to deal with a test failure: 1) If a test always fails on a fs, and can't be fixed (in case or kernel). We can add this fs type into black list of the case, e.g. _supported_fs ^$fstype 2) If a test fails on a fs as an expected bug? We have _fixed_by_xxx ... or _wants_xxx_commit helpers to record that. 3) Besides that, I generally metion some new failures in [ANNOUNCE] email of each release. (That's the last way I can choose). I hope we can fix the obvious case issue in reviewing phase, or deal with the failure by 1) or 2). For this patch, I think we can find a way to avoid the failure for btrfs, or let this test "not supported" by btrfs. Or any other better ideas :) Thanks, Zorro >
