From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, cem@kernel.org
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH 2/3] xfs_scrub: don't retry unsupported optimizations
Date: Mon, 25 Sep 2023 14:58:55 -0700 [thread overview]
Message-ID: <169567913555.2320149.9303579022453923734.stgit@frogsfrogsfrogs> (raw)
In-Reply-To: <169567912436.2320149.9404820627184014976.stgit@frogsfrogsfrogs>
From: Darrick J. Wong <djwong@kernel.org>
If the kernel says it doesn't support optimizing a data structure, we
should mark it done and move on. This is much better than requeuing the
repair, in which case it will likely keep failing. Eventually these
requeued repairs end up in the single-threaded last resort at the end of
phase 4, which makes things /very/ slow.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
scrub/scrub.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/scrub/scrub.c b/scrub/scrub.c
index e83d0d9ce99..1a4506875f7 100644
--- a/scrub/scrub.c
+++ b/scrub/scrub.c
@@ -668,6 +668,15 @@ _("Filesystem is shut down, aborting."));
return CHECK_ABORT;
case ENOTTY:
case EOPNOTSUPP:
+ /*
+ * If the kernel cannot perform the optimization that we
+ * requested; or we forced a repair but the kernel doesn't know
+ * how to perform the repair, don't requeue the request. Mark
+ * it done and move on.
+ */
+ if (is_unoptimized(&oldm) ||
+ debug_tweak_on("XFS_SCRUB_FORCE_REPAIR"))
+ return CHECK_DONE;
/*
* If we're in no-complain mode, requeue the check for
* later. It's possible that an error in another
@@ -678,13 +687,6 @@ _("Filesystem is shut down, aborting."));
*/
if (!(repair_flags & XRM_COMPLAIN_IF_UNFIXED))
return CHECK_RETRY;
- /*
- * If we forced repairs or this is a preen, don't
- * error out if the kernel doesn't know how to fix.
- */
- if (is_unoptimized(&oldm) ||
- debug_tweak_on("XFS_SCRUB_FORCE_REPAIR"))
- return CHECK_DONE;
fallthrough;
case EINVAL:
/* Kernel doesn't know how to repair this? */
next prev parent reply other threads:[~2023-09-25 21:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <iq6M2jOFTA7tpkemhj2B-jYNUxbdZWyn_T3zy7D3OK-XjdJMLzOaQp_x201-WWr0NRp1s5vaAspRGyQm7l2hqQ==@protonmail.internalid>
2023-09-25 21:58 ` [PATCHSET v26.2 0/3] xfsprogs: force rebuilding of metadata Darrick J. Wong
2023-09-25 21:58 ` [PATCH 1/3] xfs_io: support passing the FORCE_REBUILD flag to online repair Darrick J. Wong
2023-09-25 21:58 ` Darrick J. Wong [this message]
2023-09-25 21:59 ` [PATCH 3/3] xfs_scrub: try to use XFS_SCRUB_IFLAG_FORCE_REBUILD Darrick J. Wong
2023-10-03 11:33 ` [PATCHSET v26.2 0/3] xfsprogs: force rebuilding of metadata Carlos Maiolino
2023-12-20 17:11 [PATCHSET v28.3 4/4] " Darrick J. Wong
2023-12-20 17:15 ` [PATCH 2/3] xfs_scrub: don't retry unsupported optimizations Darrick J. Wong
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=169567913555.2320149.9303579022453923734.stgit@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@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