On Fri, May 17, 2024 at 12:12:50AM +0200, David Sterba wrote: > From: Josef Bacik <josef@xxxxxxxxxxxxxx> > > When testing encryption I started getting failures because the scratch > dev didn't have a valid fs at the end of the test. This is because for > encryption we have to disable raid5/6, which changes how the test is > run. > > Normally with raid6 we end up cancelling the device replace, and thus > $SCRATCH_DEV has a valid file system on it. However with raid5/6 > disabled we end with a normal DUP profile, and the replace doesn't end > up cancelled, so $SCRATCH_DEV is wiped. Then when the test finishes we > do the normal fsck and see that there's no fs on the $SCRATCH_DEV and > error. > > This test does all the fsck'ing during the workout period, so we don't > need the final scratch check, simply re-make the $SCRATCH_DEV at the end > as it could have been replaced during the test. > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> > Signed-off-by: David Sterba <dsterba@xxxxxxxx> > --- > tests/btrfs/011 | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/tests/btrfs/011 b/tests/btrfs/011 > index bf63a72b11c42f..d99624fb941cce 100755 > --- a/tests/btrfs/011 > +++ b/tests/btrfs/011 > @@ -258,6 +258,11 @@ for t in "-m single -d single:1 no 64" \ > fi > done > > +# If we exclude certain RAID profiles we can end up where the scratch dev > +# doesn't have a valid fs on it because it was replaced during workout, so mkfs > +# the scratch device so we don't get _check_btrfs_filesystem errors > +_scratch_mkfs > /dev/null 2>&1 /me wonders why the_require_scratch_nocheck at the top doesn't shut off the post-test fsck? --D > + > echo "*** done" > status=0 > exit > -- > 2.45.0 > >
