On 2021/2/25 上午9:46, Eric Sandeen wrote:
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.
The problem is, TEST_DEV should not be included in SCRATCH_DEV_POOL.
Just try assiging TEST_DEV and SCRATCH_DEV the same, that's what exactly
you're doing.
If you want to test aging on multiple-btrfs, it's not a problem at all,
just mkfs.btrfs on the array, and put one device into TEST_DEV and call
it a day.
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
Nope, it's the tester's response to setup TEST_DEV.
As mentioned, just setup TEST_DEV *properly*, you can test it without
any problem even for multi-device btrfs.
tl;dr: a btrfs test which renders a legitimate btrfs TEST_DEV inoperable is
a flaw in that btrfs test, IMHO.
The root problem is, TEST_DEV should never be included into
SCRACTH_DEV_POOL nor SCRATCH_DEV.
And obviously, putting the same device into both TEST_DEV and
SCRATCH_DEV pool is the problem.
Thanks,
Qu
-Eric
Thanks, Anand
Thanks,
-Eric
