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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 10/6/23 16:38, Zorro Lang wrote:
On Fri, Jun 09, 2023 at 07:52:53AM -0700, Darrick J. Wong wrote:
Tests ought to be cc'd to fstests@xxxxxxxxxxxxxxx.

Thanks, I got this patch now :)

Sorry Zorro, I'd meant to CC the cover letter and test to fstests.



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

As a regression test case, we need to point out that it's:
   _fixed_by_git_commit xfsprogs a4d94d6c30ac "xfs_repair: fix progress reporting"


Will do.

Then due to it might fail without the other patch [1] (which has been reviewed),
so we'd better to point out that:

   _wants_git_commit xfsprogs xxxxxxxxxxxx \
           "xfs_repair: always print an estimate when reporting progress"

[1]
https://lore.kernel.org/linux-xfs/ZIM%2FKegChkoeTJE8@xxxxxxxxxx/T/#u

I'll send a v5 to fstests and linux-xfs once the above is merged and I
can add the commit.

- Don



+_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}"

Agree


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

If the `sort -u` is necessary, how about only print the lines we realy care,
filter out all other lines?

Thanks,
Zorro

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







[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux