public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: xfs-oss <xfs@oss.sgi.com>
Subject: [PATCH] xfsdump: Revert dump version bump for 32bit projid fix
Date: Mon, 22 Oct 2012 15:24:16 -0500	[thread overview]
Message-ID: <5085AB70.2060904@redhat.com> (raw)

commit 1e309da7a4f7e2a2f456bf6b7cea4c5f1181cd36 fixed xfsdump to
properly save & restore the top 16 bits of a 32-bit projid, which
otherwise was being dropped (and restored as 0) in older xfsdump.

The original thought was to bump the dump version, so that we know
whether the dump (may) have the top 16 bits filled in.  In practice
this would prevent older restores from restoring newer dumps, and
losing the top 16 bits contained in these newer dumps.

However, in hindsight this appears to be of limited value.  I
propose that the dump version change is unuseful/unwanted for a
couple reasons:

* There is no actual dump *format* change; the structure size
  is the same, and the top 16 bits were properly zeroed before; old
  restores will read these fixed dumps without problems and without
  restoring garbage.  IOW, they will behave exactly as buggily as
  they did before.  And worst case, if a dump containing the top 16
  bits is mangled by an old restore, this can be easily remedied by
  simply re-restoring with updated userspace.

* We have no reliable method to know whether 32 bit project IDs are
  in use; the feature flag was not added to the GEOM call at the time
  of implementation.  Therefore we cannot reliably bump to V4 only
  for projid32bit filesystems, and we cannot restrict V4 restores
  only to projid32bit filesystems.  So the dump version is not
  useful for feature cross-checking purposes.

I spoke with wkendall via email, and although he may not have given
it the most scrutiny (having moved on from xfsdump-land), he also
felt that a version dump may not be warranted.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

diff --git a/common/global.c b/common/global.c
index 1793ff4..8e49d8b 100644
--- a/common/global.c
+++ b/common/global.c
@@ -281,7 +281,6 @@ global_version_check( u_int32_t version )
 		case GLOBAL_HDR_VERSION_1:
 		case GLOBAL_HDR_VERSION_2:
 		case GLOBAL_HDR_VERSION_3:
-		case GLOBAL_HDR_VERSION_4:
 			return BOOL_TRUE;
 		default:
 			return BOOL_FALSE;
diff --git a/common/global.h b/common/global.h
index 5138ed8..6556a68 100644
--- a/common/global.h
+++ b/common/global.h
@@ -28,15 +28,13 @@
 #define GLOBAL_HDR_VERSION_1	1
 #define GLOBAL_HDR_VERSION_2	2
 #define GLOBAL_HDR_VERSION_3	3
-#define GLOBAL_HDR_VERSION_4	4
-	/* version 4 adds 32-bit projid (projid_hi)
-	 * version 3 uses the full 32-bit inode generation number in direnthdr_t.
+	/* version 3 uses the full 32-bit inode generation number in direnthdr_t.
 	 * version 2 adds encoding of holes and a change to on-tape inventory format.
 	 * version 1 adds extended file attribute dumping.
 	 * version 0 xfsrestore can't handle media produced
 	 * by version 1 xfsdump. 
 	 */
-#define GLOBAL_HDR_VERSION	GLOBAL_HDR_VERSION_4
+#define GLOBAL_HDR_VERSION	GLOBAL_HDR_VERSION_3
 
 #define GLOBAL_HDR_STRING_SZ	0x100
 #define GLOBAL_HDR_TIME_SZ	4

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2012-10-22 20:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 20:24 Eric Sandeen [this message]
2012-10-22 22:31 ` [PATCH] xfsdump: Revert dump version bump for 32bit projid fix Dave Chinner
2012-10-23  0:05   ` Eric Sandeen
2012-10-23 19:51 ` Ben Myers
2012-10-26 20:31 ` Ben Myers

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=5085AB70.2060904@redhat.com \
    --to=sandeen@redhat.com \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox