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 > > > >
