From: "Darrick J. Wong" <djwong@kernel.org>
To: Donald Douwsma <ddouwsma@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4] xfstests: add test for xfs_repair progress reporting
Date: Fri, 9 Jun 2023 07:52:53 -0700 [thread overview]
Message-ID: <20230609145253.GY1325469@frogsfrogsfrogs> (raw)
In-Reply-To: <20230531064024.1737213-2-ddouwsma@redhat.com>
Tests ought to be cc'd to fstests@vger.kernel.org.
On Wed, May 31, 2023 at 04:40:24PM +1000, Donald Douwsma wrote:
> Confirm that xfs_repair reports on its progress if -o ag_stride is
> enabled.
>
> Signed-off-by: Donald Douwsma <ddouwsma@redhat.com>
> ---
> Changes since v3
> - Rebase after tests/xfs/groups removal (tools/convert-group), drop _supported_os
> - Shorten the delay, remove superfluous dm-delay parameters
> Changes since v2:
> - Fix cleanup handling and function naming
> - Added to auto group
> 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/999 | 66 +++++++++++++++++++++++++++++++++++++++++++++++
> tests/xfs/999.out | 15 +++++++++++
> 2 files changed, 81 insertions(+)
> create mode 100755 tests/xfs/999
> create mode 100644 tests/xfs/999.out
>
> diff --git a/tests/xfs/999 b/tests/xfs/999
> new file mode 100755
> index 00000000..9e799f66
> --- /dev/null
> +++ b/tests/xfs/999
> @@ -0,0 +1,66 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2020 Red Hat, Inc. All Rights Reserved.
> +#
> +# FS QA Test 521
> +#
> +# Test xfs_repair's progress reporting
> +#
> +. ./common/preamble
> +_begin_fstest auto repair
> +
> +# Override the default cleanup function.
> +_cleanup()
> +{
> + cd /
> + rm -f $tmp.*
> + _cleanup_delay > /dev/null 2>&1
> +}
> +
> +# Import common functions.
> +. ./common/filter
> +. ./common/dmdelay
> +. ./common/populate
> +
> +# real QA test starts here
> +
> +# Modify as appropriate.
> +_supported_fs xfs
> +_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/' xfsprogs-dev/repair/progress.c
> +filter_repair()
> +{
> + sed -nre '
> + s/[0-9]+/#/g;
> + s/^\s+/ /g;
> + s/(# (week|day|hour|minute|second)s?(, )?)+/{progres}/g;
> + /#:#:#:/p
> + '
> +}
> +
> +echo "Format and populate"
> +_scratch_populate_cached nofill > $seqres.full 2>&1
> +
> +echo "Introduce a dmdelay"
> +_init_delay
> +DELAY_MS=38
I wonder if this is where _init_delay should gain a delay_ms argument?
_init_delay() {
local delay_ms="${1:-10000}"
...
DELAY_TABLE_RDELAY="0 $BLK_DEV_SIZE delay $SCRATCH_DEV 0 $delay_ms $SCRATCH_DEV 0 0"
}
> +# 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 $DELAY_MS"
> +_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 > $tmp.repair
> +
> +cat $tmp.repair | filter_repair | sort -u
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/xfs/999.out b/tests/xfs/999.out
> new file mode 100644
> index 00000000..e27534d8
> --- /dev/null
> +++ b/tests/xfs/999.out
> @@ -0,0 +1,15 @@
> +QA output created by 999
> +Format and populate
> +Introduce a dmdelay
> +Run repair
> + - #:#:#: Phase #: #% done - estimated remaining time {progres}
> + - #:#:#: Phase #: elapsed time {progres} - 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
Otherwise seems fine to me, assuming nothing goes nuts if rt devices or
whatever happen to be configured. ;)
--D
> --
> 2.39.3
>
next prev parent reply other threads:[~2023-06-09 14:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 6:40 [PATCH 0/2] xfstests/xfsprogs xfs_repair progress reporting test Donald Douwsma
2023-05-31 6:40 ` [PATCH v4] xfstests: add test for xfs_repair progress reporting Donald Douwsma
2023-06-09 1:50 ` Murphy Zhou
2023-06-09 3:36 ` Zorro Lang
2023-06-09 14:52 ` Darrick J. Wong [this message]
2023-06-10 6:38 ` Zorro Lang
2023-06-15 2:15 ` Donald Douwsma
2023-05-31 6:41 ` [PATCH] xfs_repair: always print an estimate when reporting progress Donald Douwsma
2023-06-09 14:48 ` Darrick J. Wong
2023-06-09 15:03 ` Bill O'Donnell
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=20230609145253.GY1325469@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=ddouwsma@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.