On 2/24/21 7:16 PM, Anand Jain wrote: > On 25/02/2021 05:39, Eric Sandeen wrote: >> On 2/24/21 10:12 AM, Eric Sandeen wrote: >>> Last week I was curious to just see how btrfs is faring with RAID5 in >>> xfstests, so I set it up for a quick run with devices configured as: >> >> Whoops this was supposed to cc: fstests, not fsdevel, sorry. >> >> -Eric >> >>> TEST_DEV=/dev/sdb1 # <--- this was a 3-disk "-d raid5" filesystem >>> SCRATCH_DEV_POOL="/dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6" >>> >>> and fired off ./check -g auto >>> >>> Every test after btrfs/124 fails, because that test btrfs/124 does this: >>> >>> # un-scan the btrfs devices >>> _btrfs_forget_or_module_reload >>> >>> and nothing re-scans devices after that, so every attempt to mount TEST_DEV >>> will fail: >>> >>>> devid 2 uuid e42cd5b8-2de6-4c85-ae51-74b61172051e is missing" >>> >>> Other btrfs tests seeme to have the same problem. >>> >>> If xfstest coverage on multi-device btrfs volumes is desired, it might be >>> a good idea for someone who understands the btrfs framework in xfstests >>> to fix this. > > Eric, > > All our multi-device test-cases under tests/btrfs used the > SCRATCH_DEV_POOL. Unless I am missing something, any idea if > TEST_DEV can be made optional for test cases that don't need TEST_DEV? > OR I don't understand how TEST_DEV is useful in some of these > test-cases under tests/btrfs. Those are the tests specifically designed to poke at multi-dev btrfs, right. TEST_DEV is more designed to "age" - it is used for more non-destructive tests. The point is that many tests /d/o run using TEST_DEV, and if a multi-dev TEST_DEV can't be used, you are getting no coverage from those tests on that type of btrfs configuration. And if a multi-dev TEST_DEV breaks the test run, nobody's going to test that way. There are ~300 tests that run on TEST_DEV, and restricting its functionality to a single-device btrfs filesytem misses coverage. # grep require_test tests/generic/??? | wc -l 299 tl;dr: a btrfs test which renders a legitimate btrfs TEST_DEV inoperable is a flaw in that btrfs test, IMHO. -Eric > Thanks, Anand > >>> >>> Thanks, >>> -Eric >>> >
