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

[Donald Douwsma <ddouwsma@redhat.com>]

Hi Zorry, 

On 11/06/2020 15:03, Zorro Lang wrote:
> 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:)

Will do,

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

Ok, I'll submit with it added to the auto group as well. 

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

I think boring may be safer if its going into the auto group.

I'd like to stick with the boring filter to start with, I dont want to make it
too fragile if the image changes. 

>>>
>>
>>
>