All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, guaneryu@gmail.com
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me
Subject: [PATCH 1/2] common/xfs: skip xfs_check unless the test runner forces us to
Date: Tue, 31 Aug 2021 17:11:16 -0700	[thread overview]
Message-ID: <163045507618.769821.3650550873572768945.stgit@magnolia> (raw)
In-Reply-To: <163045507051.769821.5924414818977330640.stgit@magnolia>

From: Darrick J. Wong <djwong@kernel.org>

At long last I've completed my quest to ensure that every corruption
found by xfs_check can also be found by xfs_repair.  Since xfs_check
uses more memory than repair and has long been obsolete, let's stop
running it automatically from _check_xfs_filesystem unless the test
runner makes us do it.

Tests that explicitly want xfs_check can call it via _scratch_xfs_check
or _xfs_check; that part doesn't go away.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 README     |    4 ++++
 common/xfs |   12 ++++++++----
 2 files changed, 12 insertions(+), 4 deletions(-)


diff --git a/README b/README
index 84c217ce..63f0641a 100644
--- a/README
+++ b/README
@@ -125,6 +125,10 @@ Preparing system for tests:
 	       time we should try a patient module remove. The default is 50
 	       seconds. Set this to "forever" and we'll wait forever until the
 	       module is gone.
+             - Set FORCE_XFS_CHECK_PROG=yes to have _check_xfs_filesystem run
+               xfs_check to check the filesystem.  As of August 2021,
+               xfs_repair finds all filesystem corruptions found by xfs_check,
+               and more, which means that xfs_check is no longer run by default.
 
         - or add a case to the switch in common/config assigning
           these variables based on the hostname of your test
diff --git a/common/xfs b/common/xfs
index c5e39427..bfb1bf1e 100644
--- a/common/xfs
+++ b/common/xfs
@@ -595,10 +595,14 @@ _check_xfs_filesystem()
 		ok=0
 	fi
 
-	# xfs_check runs out of memory on large files, so even providing the test
-	# option (-t) to avoid indexing the free space trees doesn't make it pass on
-	# large filesystems. Avoid it.
-	if [ "$LARGE_SCRATCH_DEV" != yes ]; then
+	# xfs_check runs out of memory on large files, so even providing the
+	# test option (-t) to avoid indexing the free space trees doesn't make
+	# it pass on large filesystems. Avoid it.
+	#
+	# As of August 2021, xfs_repair completely supersedes xfs_check's
+	# ability to find corruptions, so we no longer run xfs_check unless
+	# forced to run it.
+	if [ "$LARGE_SCRATCH_DEV" != yes ] && [ "$FORCE_XFS_CHECK_PROG" = "yes" ]; then
 		_xfs_check $extra_log_options $device 2>&1 > $tmp.fs_check
 	fi
 	if [ -s $tmp.fs_check ]; then


  reply	other threads:[~2021-09-01  0:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  0:11 [PATCHSET 0/2] fstests: random fixes Darrick J. Wong
2021-09-01  0:11 ` Darrick J. Wong [this message]
2021-09-01  8:30   ` [PATCH 1/2] common/xfs: skip xfs_check unless the test runner forces us to Christoph Hellwig
2021-09-01  9:24   ` Zorro Lang
2021-09-01  0:11 ` [PATCH 2/2] generic/643: fix weird problems on 64k-page arm systems Darrick J. Wong
2021-09-01  8:34   ` Christoph Hellwig

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=163045507618.769821.3650550873572768945.stgit@magnolia \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=guaneryu@gmail.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.