On Sun, Mar 02, 2025 at 09:50:16AM -0500, Theodore Ts'o wrote: > On Sun, Mar 02, 2025 at 01:13:43PM +0000, Filipe Manana wrote: > > Or another example, a fix from Ted, for a generic test case that > > always failed on ext4: > > > > https://web.git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=023070744cef1fde8a5b4fbd8fa134cd5098843e > > > > Actually, this fixed a bug which affected file systems for all file > systems *except* xfs, since the generic bug was injecting an > XFS-specific mkfs option into _scratch_mkfs. This was a *really* > obvious bug, but the problem was that commit 000813899afb ("fstests: > scale some tests for high CPU count sanity") made *huge* number of > changes, which made it hard to review the change, and also made it > harder for Dave to rebase the change, which is why, apparently, > pressure was applied to merge commit 000813899afb right before Dave > diappeared on vacation for a month. This is why I nated that there > appeared to be a double standarrd in place; I can't help but suspect > that if anyone *else* had sent in this commit, it would have been > rejected. > > As far as testing, my understanding is that the huge amount of testing > happens between the promotion from for-next to the master branch. > This is why I used to make a point of upgrading my test appliance to > for-next, so I could help point out problems before most other > deveopers would see it in the master branch. Hi Ted, Sorry, I was hurry to make a big step on xfstests... Although I just brought in btrfs test into my regular test list recently (RHEL doesn't support btrfs, I don't have the experience to test it). But ext4 is supported by us, I test ext4/3 with 1k/4k blocksize, fsverity, dax before each xfstests release. Last ext4 regression test on v2025.02.23 was all passed on my side, except 4 known failures on g/044, g/045, g/046 and g/388: XFSTESTS_END/[passed:542][notrun:259][known:4][unknown:0] PASS Score:0 Do I miss anything on extN testing, cause I didn't find most of test failures on ext4? Please feel free to tell me what is better to be tested on ext4 side before release xfstests, and what's optional. I'll try to add it to my test list. Thanks, Zorro > > The fixes that you pointed out was all reasons why the master branch > hadn't been updated in months; it was because for-next still had > breakages. There is the challenge that when master hasn't gotten > updated for 2 or 3 months, it becomes harder to tell whether a test > failure was caused by a test bug, or a kernel bug. (It's not > impossible; for a while I was going to older versions of for-next, and > the comparing the results to newer versions of for-next, and then > filtering out new tests, but it's a bit of a pain.) > > Ultimately, like most engineering tradeoffs this was a pain allocation > exercise. Dave didn't want to deal with rebasing changes, so the > check-parallel changes got merged to for-next early. This inflicted > pain on other xfstests developers. > > - Ted >
