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

["Darrick J. Wong" <djwong@kernel.org>]

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?

--D

> +
>  echo "*** done"
>  status=0
>  exit
> -- 
> 2.45.0
> 
>