Re: [PATCH 5/6] btrfs/011: mkfs the scratch dev before exiting

[David Sterba <dsterba@suse.cz>]

On Fri, May 17, 2024 at 08:37:54AM -0700, Darrick J. Wong wrote:
> On Fri, May 17, 2024 at 12:12:50AM +0200, David Sterba wrote:
> > From: Josef Bacik <josef@toxicpanda.com>
> > 
> > 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@toxicpanda.com>
> > Signed-off-by: David Sterba <dsterba@suse.com>
> > ---
> >  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?

I think Josef did this when adding encryption support and tests and had
a reason for that, but I don't know why or what was the error.  This
patch can be skipped in case the rest is OK, we'll keep in our local
branch and reevaluate it again before sending.