My 3.17-rc1 regression results show new failures for 10 xfstests when run on a bigalloc file system using the test infrastructure from xfstests-bld. (Ted reported similar failures on a pre-3.17-rc1 kernel recently.) The failures include generic/012, generic/016, generic/017, generic/021, generic/022, generic/075, generic/091, generic/112, generic/127, and generic/263. They occur on an x86_64 virtual machine as well as on a Pandaboard (ARM). All involve EINVAL returns from fallocate() with COLLAPSE_RANGE. They are related to this patch which enabled collapse range for bigalloc: ee98fa3a8b ext4: fix COLLAPSE RANGE test for bigalloc file systems (Reverting it in 3.17-rc1 restores the test behavior observed in my 3.16 baseline. The first five tests reported above were not run in that baseline because collapse range was disabled for bigalloc in 3.16 and this prevented them from running (_require_xfs_io_command "fcollapse"). The latter five yielded EOPNOTSUPP returns and thus test failures, again because collapse range was disabled in the 3.16 kernel.) The root cause is that each of the failed tests in 3.17-rc1 generates collapse range offset and/or length values that are guaranteed to fail the new test in ee98fa3a8b intended to assure that offsets are aligned on cluster boundaries and that lengths are multiples of clusters. In fact, none of the tests generates values that are legal in xfstest-bld's bigalloc test scenario (cluster size is 64 KB), so there does not currently appear to be any useful xfstest test coverage for the collapse range feature on 4 KB block bigalloc file systems. There is at least some useful coverage in the bigalloc_1k scenario (cluster size is 16 KB), where the list of failures related to collapse range does not include generic/012, generic/016, generic/021, and generic/022. That's because those tests happen to generate collapse range requests whose offset and length values align on 16 KB boundaries or which are multiples of 16 KB in length. However, generic/017 does not generate legal offset and/or length values for the bigalloc_1k scenario, and neither do generic/075, generic/091, generic/112, generic/127, or generic/263. There's obviously nothing wrong with verifying that illegal values are handled correctly, but that's not the case here. Perhaps it's a little early to enable collapse range for bigalloc on ext4 unless the tests can be improved to provide better coverage. FWIW, this is by far the worst of the regressions I'm seeing in 3.17-rc1 - there are just a few items besides this, and overall it's looking pretty good. Test system configuration: e2fsprogs - master branch, 489ff4a2c7 xfsprogs - master branch, ba24eb7c82 xfstests - master branch, f7d0a30629 xfstests-bld - master branch, 3c375bae76 Thanks, Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
