All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, zlang@redhat.com
Cc: Christoph Hellwig <hch@lst.de>, Zorro Lang <zlang@kernel.org>,
	linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me
Subject: [PATCH 09/10] common/xfs: only pass -l in _xfs_mdrestore for v2 metadumps
Date: Tue, 06 Feb 2024 18:19:25 -0800	[thread overview]
Message-ID: <170727236500.3726171.13197353676937666826.stgit@frogsfrogsfrogs> (raw)
In-Reply-To: <170727231361.3726171.14834727104549554832.stgit@frogsfrogsfrogs>

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

fstests has a weird history with external log devices -- prior to the
introduction of metadump v2, a dump/restore cycle would leave an
external log unaltered, and most tests worked just fine.  Were those
tests ignorant?  Or did they pass intentionally?

Either way, we don't want to pass -l to xfs_mdrestore just because we
have an external log, because that switch is new and causes regressions
when testing with xfsprogs from before 6.5.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>
---
 common/xfs |   25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)


diff --git a/common/xfs b/common/xfs
index 6a48960a7f..65b509691b 100644
--- a/common/xfs
+++ b/common/xfs
@@ -689,12 +689,25 @@ _xfs_metadump() {
 	return $res
 }
 
+# What is the version of this metadump file?
+_xfs_metadumpfile_version() {
+	local file="$1"
+	local magic
+
+	magic="$($XFS_IO_PROG -c 'pread -q -v 0 4' "$file")"
+	case "$magic" in
+	"00000000:  58 4d 44 32  XMD2") echo 2;;
+	"00000000:  58 46 53 4d  XFSM") echo 1;;
+	esac
+}
+
 _xfs_mdrestore() {
 	local metadump="$1"
 	local device="$2"
 	local logdev="$3"
 	shift; shift; shift
 	local options="$@"
+	local dumpfile_ver
 
 	# If we're configured for compressed dumps and there isn't already an
 	# uncompressed dump, see if we can use DUMP_COMPRESSOR to decompress
@@ -705,8 +718,18 @@ _xfs_mdrestore() {
 		done
 	fi
 	test -r "$metadump" || return 1
+	dumpfile_ver="$(_xfs_metadumpfile_version "$metadump")"
 
-	if [ "$logdev" != "none" ]; then
+	if [ "$logdev" != "none" ] && [[ $dumpfile_ver > 1 ]]; then
+		# metadump and mdrestore began capturing and restoring the
+		# contents of external log devices with the addition of the
+		# metadump v2 format.  Hence it only makes sense to specify -l
+		# here if the dump file itself is in v2 format.
+		#
+		# With a v1 metadump, the log device is not changed by the dump
+		# and restore process.  Historically, fstests either didn't
+		# notice or _notrun themselves when external logs were in use.
+		# Don't break that for people testing with xfsprogs < 6.5.
 		options="$options -l $logdev"
 	fi
 


  parent reply	other threads:[~2024-02-07  2:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07  2:18 [PATCHSET] fstests: random fixes for v2024.01.14 Darrick J. Wong
2024-02-07  2:18 ` [PATCH 01/10] generic/256: constrain runtime with TIME_FACTOR Darrick J. Wong
2024-02-07  2:18 ` [PATCH 02/10] common/xfs: simplify maximum metadump format detection Darrick J. Wong
2024-02-07  2:18 ` [PATCH 03/10] common/populate: always metadump full metadata blocks Darrick J. Wong
2024-02-07  2:18 ` [PATCH 04/10] xfs/336: fix omitted -a and -o in metadump call Darrick J. Wong
2024-02-07  2:19 ` [PATCH 05/10] common: refactor metadump v1 and v2 tests, version 2 Darrick J. Wong
2024-02-07  9:15   ` Zorro Lang
2024-02-07  2:19 ` [PATCH 06/10] xfs/{129,234,253,605}: disable metadump v1 testing with external devices Darrick J. Wong
2024-02-07  2:19 ` [PATCH 07/10] xfs/503: test metadump obfuscation, not progressbars Darrick J. Wong
2024-02-07  2:19 ` [PATCH 08/10] xfs/503: split copy and metadump into two tests Darrick J. Wong
2024-02-07  2:19 ` Darrick J. Wong [this message]
2024-02-07  2:19 ` [PATCH 10/10] xfs/122: fix for xfs_attr_shortform removal in 6.8 Darrick J. Wong
  -- strict thread matches above, loose matches on Subject: below --
2024-01-25 19:04 [PATCHSET] fstests: random fixes for v2024.01.14 Darrick J. Wong
2024-01-25 19:06 ` [PATCH 09/10] common/xfs: only pass -l in _xfs_mdrestore for v2 metadumps Darrick J. Wong
2024-01-26 13:36   ` 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=170727236500.3726171.13197353676937666826.stgit@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@kernel.org \
    --cc=zlang@redhat.com \
    /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.