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 >
