Sure, will send out another set. Thanks! On Fri, Apr 14, 2023 at 5:41 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Fri, Apr 14, 2023 at 03:11:33PM -0700, Leah Rumancik wrote: > > Previously, we would only run _check_filesystems to ensure that a test > > that appeared to pass did not have any filesystem corruption. However, > > in _check_filesystems, we also repair any errors found in the filesystem. > > Let's do this even if we already know the test failed so that subsequent > > tests aren't affected. > > > > Signed-off-by: Leah Rumancik <leah.rumancik@xxxxxxxxx> > > --- > > check | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/check b/check > > index befbf465..c18f02ca 100755 > > --- a/check > > +++ b/check > > @@ -972,6 +972,7 @@ function run_section() > > # Even though we failed, there may be something interesting in > > # dmesg which can help debugging. > > _check_dmesg > > + (_adjust_oom_score 250; _check_filesystems) > > Seeing as the test failed, do we care about the state of the scratch fs? > Would it be sufficient only to clean up the test fs to avoid cascading > damage? > > (Asking as someone who knows how impactful slow filesystem checking can > be on fstests runtimes... ;)) > > --D > > > tc_status="fail" > > else > > # The test apparently passed, so check for corruption > > -- > > 2.40.0.634.g4ca3ef3211-goog > >
