linux-xfs.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).