fstests.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Donald Douwsma <ddouwsma@redhat.com>
To: linux-xfs@vger.kernel.org, fstests@vger.kernel.org,
	"Darrick J . Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH v2] xfstests: add test for xfs_repair progress reporting
Date: Mon, 1 Jun 2020 10:53:59 +1000	[thread overview]
Message-ID: <3097a996-c661-d03f-a3e6-aa60ea808f04@redhat.com> (raw)
In-Reply-To: <20200529080640.GH1938@dhcp-12-102.nay.redhat.com>

Hi Zorro,

On 29/05/2020 18:06, Zorro Lang wrote:
> On Wed, May 20, 2020 at 01:52:58PM +1000, Donald Douwsma wrote:
>> xfs_repair's interval based progress has been broken for
>> some time, create a test based on dmdelay to stretch out
>> the time and use ag_stride to force parallelism.
>>
>> Signed-off-by: Donald Douwsma <ddouwsma@redhat.com>
>> ---
>> Changes since v1:
>> - Use _scratch_xfs_repair
>> - Filter only repair output
>> - Make the filter more tolerant of whitespace and plurals
>> - Take golden output from 'xfs_repair: fix progress reporting'
>>
>>  tests/xfs/516     | 76 +++++++++++++++++++++++++++++++++++++++++++++++
>>  tests/xfs/516.out | 15 ++++++++++
>>  tests/xfs/group   |  1 +
>>  3 files changed, 92 insertions(+)
>>  create mode 100755 tests/xfs/516
>>  create mode 100644 tests/xfs/516.out
>>
>> diff --git a/tests/xfs/516 b/tests/xfs/516
>> new file mode 100755
>> index 00000000..1c0508ef
>> --- /dev/null
>> +++ b/tests/xfs/516
>> @@ -0,0 +1,76 @@
>> +#! /bin/bash
>> +# SPDX-License-Identifier: GPL-2.0
>> +# Copyright (c) 2020 Red Hat, Inc.  All Rights Reserved.
>> +#
>> +# FS QA Test 516
>> +#
>> +# Test xfs_repair's progress reporting
>> +#
>> +seq=`basename $0`
>> +seqres=$RESULT_DIR/$seq
>> +echo "QA output created by $seq"
>> +
>> +here=`pwd`
>> +tmp=/tmp/$$
>> +status=1	# failure is the default!
>> +trap "_cleanup; exit \$status" 0 1 2 3 15
>> +
>> +_cleanup()
>> +{
>> +	cd /
>> +	_dmsetup_remove delay-test > /dev/null 2>&1
> 
> How about use the helper, avoid using the 'delay-test' name at here?
> _cleanup_delay > /dev/null 2>&1
> 
>> +}
>> +
>> +# get standard environment, filters and checks
>> +. ./common/rc
>> +. ./common/filter
>> +. ./common/dmdelay
>> +. ./common/populate
>> +
>> +# remove previous $seqres.full before test
>> +rm -f $seqres.full
>> +
>> +# real QA test starts here
>> +
>> +# Modify as appropriate.
>> +_supported_fs xfs
>> +_supported_os Linux
>> +_require_scratch
>> +_require_dm_target delay
>> +
>> +# Filter output specific to the formatters in xfs_repair/progress.c
>> +# Ideally we'd like to see hits on anything that matches
>> +# awk '/{FMT/' repair/progress.c
>> +_filter_repair()
>> +{
>> +	sed -ne '
>> +	s/[0-9]\+/#/g;
>> +	s/^\s\+/ /g;
>> +	s/\(second\|minute\)s/\1/g
>> +	/#:#:#:/p
>> +	'
>> +}
>> +
>> +echo "Format and populate"
>> +_scratch_populate_cached nofill > $seqres.full 2>&1
>> +
>> +echo "Introduce a dmdelay"
>> +_init_delay
>> +
>> +# Introduce a read I/O delay
>> +# The default in common/dmdelay is a bit too agressive
>> +BLK_DEV_SIZE=`blockdev --getsz $SCRATCH_DEV`
>> +DELAY_TABLE_RDELAY="0 $BLK_DEV_SIZE delay $SCRATCH_DEV 0 100 $SCRATCH_DEV 0 0"
>> +_load_delay_table $DELAY_READ
>> +
>> +echo "Run repair"
>> +SCRATCH_DEV=$DELAY_DEV _scratch_xfs_repair -o ag_stride=4 -t 1 2>&1 |
>> +        tee -a $seqres.full > $seqres.xfs_repair.out
>> +
>> +cat $seqres.xfs_repair.out | _filter_repair | sort -u
>> +
>> +_cleanup_delay
>> +
>> +# success, all done
>> +status=0
>> +exit
>> diff --git a/tests/xfs/516.out b/tests/xfs/516.out
>> new file mode 100644
>> index 00000000..85018b93
>> --- /dev/null
>> +++ b/tests/xfs/516.out
>> @@ -0,0 +1,15 @@
>> +QA output created by 516
>> +Format and populate
>> +Introduce a dmdelay
>> +Run repair
>> + - #:#:#: Phase #: #% done - estimated remaining time # minute, # second
> 
> I just tested on latest upstream xfsprogs-dev for-next branch, it failed as:
> --- /root/git/xfstests-dev/tests/xfs/516.out    2020-05-29 15:31:06.602440261 +0800
> +++ /root/git/xfstests-dev/results//xfs/516.out.bad     2020-05-29 15:40:13.401777675 +0800
> @@ -3,6 +3,7 @@
>  Introduce a dmdelay
>  Run repair
>   - #:#:#: Phase #: #% done - estimated remaining time # minute, # second
> + - #:#:#: Phase #: #% done - estimated remaining time # second
>   - #:#:#: Phase #: elapsed time # second - processed # inodes per minute
>   - #:#:#: check for inodes claiming duplicate blocks - # of # inodes done
>   - #:#:#: process known inodes and inode discovery - # of # inodes done
> 
> 
>> + - #:#:#: Phase #: elapsed time # second - processed # inodes per minute
>> + - #:#:#: check for inodes claiming duplicate blocks - # of # inodes done
>> + - #:#:#: process known inodes and inode discovery - # of # inodes done
>> + - #:#:#: process newly discovered inodes - # of # allocation groups done
>> + - #:#:#: rebuild AG headers and trees - # of # allocation groups done
>> + - #:#:#: scanning agi unlinked lists - # of # allocation groups done
>> + - #:#:#: scanning filesystem freespace - # of # allocation groups done
>> + - #:#:#: setting up duplicate extent list - # of # allocation groups done
>> + - #:#:#: verify and correct link counts - # of # allocation groups done
>> + - #:#:#: zeroing log - # of # blocks done
>> diff --git a/tests/xfs/group b/tests/xfs/group
>> index 12eb55c9..aeeca23f 100644
>> --- 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.

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.

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?

Cheers, 
Don



  reply	other threads:[~2020-06-01  0:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  6:55 [PATCH] xfstests: add test for xfs_repair progress reporting Donald Douwsma
2020-05-19 16:01 ` Darrick J. Wong
2020-05-20  1:11   ` Donald Douwsma
2020-05-20  3:52   ` [PATCH v2] " Donald Douwsma
2020-05-20 15:55     ` Darrick J. Wong
2020-05-24 16:46     ` Eryu Guan
2020-05-24 17:18       ` Darrick J. Wong
2020-08-17  7:49       ` Donald Douwsma
2020-08-17  7:53       ` [PATCH v3] " Donald Douwsma
2020-08-30 15:57         ` Eryu Guan
2020-09-02  9:04           ` Donald Douwsma
2020-05-29  8:06     ` [PATCH v2] " Zorro Lang
2020-06-01  0:53       ` Donald Douwsma [this message]
2020-06-01  3:55         ` Donald Douwsma
2020-06-11  5:03           ` Zorro Lang
2020-08-17  6:25             ` Donald Douwsma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3097a996-c661-d03f-a3e6-aa60ea808f04@redhat.com \
    --to=ddouwsma@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).