[3/5] xfs_scrub: fix threadcount estimates for phase 6

Commit Message

Darrick J. Wong April 16, 2024, 12:59 a.m. UTC

From: Darrick J. Wong <[e-mail]>

If a filesystem has a realtime device or an external log device, the
media scan can start up a separate readverify controller (and workqueue)
to handle that.  Each of those controllers can call progress_add, so we
need to bump up nr_threads so that the progress reports controller knows
to make its ptvar big enough to handle all these threads.

Signed-off-by: Darrick J. Wong <[e-mail]>
---
 scrub/phase6.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Christoph Hellwig April 16, 2024, 4:53 a.m. UTC | #1

Looks good:

Reviewed-by: Christoph Hellwig <[e-mail]>

Patch

diff --git a/scrub/phase6.c b/scrub/phase6.c
index 99a32bc79620..393d9eaa83d8 100644
--- a/scrub/phase6.c
+++ b/scrub/phase6.c
@@ -743,7 +743,17 @@  phase6_estimate(
 
 	*items = cvt_off_fsb_to_b(&ctx->mnt,
 			(d_blocks - d_bfree) + (r_blocks - r_bfree));
+
+	/*
+	 * Each read-verify pool starts a thread pool, and each worker thread
+	 * can contribute to the progress counter.  Hence we need to set
+	 * nr_threads appropriately to handle that many threads.
+	 */
 	*nr_threads = disk_heads(ctx->datadev);
+	if (ctx->rtdev)
+		*nr_threads += disk_heads(ctx->rtdev);
+	if (ctx->logdev)
+		*nr_threads += disk_heads(ctx->logdev);
 	*rshift = 20;
 	return 0;
 }