Message ID | 19804c4e3c319678768d5d24a15b000e05dd0af2.1715896529.git.dsterba@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Btrfs test updates and fixups | expand |
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 > >
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.
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 + echo "*** done" status=0 exit