On Thu, May 09, 2024 at 02:54:12PM +0200, hch@xxxxxx wrote: > On Thu, May 09, 2024 at 05:42:08PM +0800, Zorro Lang wrote: > > Hmm, what kind of situation is this _expected_failure for? > > Well, the one we are talking about here. We have a new and useful > test, and a file systems fails it because it has a bug. > > Personally I'd be fine with just letting it fail, but you seemed to > indicate that this is a reason to not merge the test yet. The failure itself is not the reason to not merge :) It's not clear what this case tests for, especially there's a failure. If it's a regression test case, we can mark the kernel commit. Or if we treat it as a simple stress test for "garbage collection in file systems", does it bring in more test coverage? As the "garbage collection" is common, most of random stress test cases cover that. But sure, I can treat it as a generic version of btrfs/273. It's copied from btrfs case, then fail on btrfs. So I hope to know what's wrong :) > > > 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 :) > > It is a normal use case that every file system should handle and btrfs > developers are looking into it, but it might take a while. If it needs longer time to fix, and if btrfs list (has known and) doesn't mind this failure, I can merge it into "patches-in-queue" branch at first. If we find a way to fix it before next release, let's fix, or I'll push it. Does that make sense to you? (CC btrfs list) Thanks, Zorro >
