Re: [PATCH v2] xfstests: add test for xfs_repair progress reporting

[Zorro Lang <zlang@redhat.com>]

On Mon, Jun 01, 2020 at 01:55:49PM +1000, Donald Douwsma wrote:
> 
> 
> On 01/06/2020 10:53, Donald Douwsma wrote:
> > Hi Zorro,
> > 
> > On 29/05/2020 18:06, Zorro Lang wrote:
> >> On Wed, May 20, 2020 at 01:52:58PM +1000, Donald Douwsma wrote:
> 
> <snip>
> 
> >>> --- a/tests/xfs/group
> >>> +++ b/tests/xfs/group
> >>> @@ -513,3 +513,4 @@
> >>>  513 auto mount
> >>>  514 auto quick db
> >>>  515 auto quick quota
> >>> +516 repair
> >>
> >> Is there a reason why this case shouldn't be in auto group?
> >>
> >> Thanks,
> >> Zorro
> > 
> > 
> > We could work to wards getting it into auto, I wanted to make sure it
> > was working ok first.

I just rechecked the mail list, sorry I missed this email long time (CC me will
make sure I won't miss it next time:)

I think several minutes running time is acceptable to be into auto group, if the
case is stable enough, won't fail unexpected.

> > 
> > It takes about 2.5 min to run with the current image used by
> > _scratch_populate_cached, by its nature it needs time for the progress
> > code to fire, but that may be ok.
> > 
> > It sometimes leaves the delay-test active, I think because I've I used
> > _dmsetup_remove in _cleanup instead of _cleanup_delay because the later
> > unmounts the filesystem, which this test doesnt do, but I'd have to look
> > into this more so it plays well with other tests like the original
> > dmdelay unmount test 311.
> 
> Actually it does clean up delay-test correctly (*cough* I may have been
> backgrounding xfs_repair in my xfstests tree while testing something
> else).  I have seen it leave delay-test around if terminated with 
> ctrl+c, but that seems reasonable if a test is aborted. 

If use a common helper to DO a test, I'd like to use its corresponding
helper to cleanup UNDO it. If there's still something wrong, we can fix the
helpers.

> 
> > I wasn't completely happy with the filter, it only checks that any of the
> > progress messages are printing at least once, which for most can still
> > just match on the end of phase printing, which always worked. Ideally it
> > would check that some of these messages print multiple times.
> > 
> > I can work on a V3 if this hasn't merged yet, or a follow up after, thoughts?

Sure, hope the V3 can improve the output mismatch issue, although the filter is
really boring:)

Thanks,
Zorro

> > 
> 
>