[PATCH] xfs_copy: accept XFS_ABTB_CRC_MAGIC

[PATCH] xfs_copy: accept XFS_ABTB_CRC_MAGIC

[Eric Sandeen]

xfs_copy needs a fair bit of work for CRCs because it rewrites
UUIDs by default, but this change will get it working properly
with the "-d" (duplicate) option which keeps the same UUID.

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

However, I wonder if we should fail CRC filesystems outright
for now if -d isn't specified, because it will invalidate every
CRC and generally make a mess of things...

diff --git a/copy/xfs_copy.c b/copy/xfs_copy.c
index 9986fbf..7c807a4 100644
--- a/copy/xfs_copy.c
+++ b/copy/xfs_copy.c
@@ -957,7 +957,9 @@ main(int argc, char **argv)
 				 ((char *)btree_buf.data +
 				  pos - btree_buf.position);
 
-			ASSERT(be32_to_cpu(block->bb_magic) == XFS_ABTB_MAGIC);
+			ASSERT(be32_to_cpu(block->bb_magic) == 
+				(xfs_sb_version_hascrc(&mp->m_sb) ?
+				 XFS_ABTB_CRC_MAGIC : XFS_ABTB_MAGIC));
 
 			if (be16_to_cpu(block->bb_level) == 0)
 				break;

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

Re: [PATCH] xfs_copy: accept XFS_ABTB_CRC_MAGIC

[Christoph Hellwig]

On Tue, Feb 25, 2014 at 08:03:20PM -0600, Eric Sandeen wrote:
> xfs_copy needs a fair bit of work for CRCs because it rewrites
> UUIDs by default, but this change will get it working properly
> with the "-d" (duplicate) option which keeps the same UUID.

I don't think ASSERTs for user supplied data are a good idea, this
should be some real error handling.

> However, I wonder if we should fail CRC filesystems outright
> for now if -d isn't specified, because it will invalidate every
> CRC and generally make a mess of things...

Yeah, for now it probably should be rejected.

It would also be useful to have a list of such issues in an README.v5
or TODO.v5 file in the xfsprogs tree.

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

Re: [PATCH] xfs_copy: accept XFS_ABTB_CRC_MAGIC

[Dave Chinner]

On Tue, Feb 25, 2014 at 06:07:37PM -0800, Christoph Hellwig wrote:
> On Tue, Feb 25, 2014 at 08:03:20PM -0600, Eric Sandeen wrote:
> > xfs_copy needs a fair bit of work for CRCs because it rewrites
> > UUIDs by default, but this change will get it working properly
> > with the "-d" (duplicate) option which keeps the same UUID.
> 
> I don't think ASSERTs for user supplied data are a good idea, this
> should be some real error handling.
> 
> > However, I wonder if we should fail CRC filesystems outright
> > for now if -d isn't specified, because it will invalidate every
> > CRC and generally make a mess of things...
> 
> Yeah, for now it probably should be rejected.
> 
> It would also be useful to have a list of such issues in an README.v5
> or TODO.v5 file in the xfsprogs tree.

Well, I thought we had just about got everything except for the
remaining repair cleanups and the logprint failure in xfs/295 up
until Eric mentioned UUIDs and xfs_copy/xfs_admin yesterday on IIRC.
I can't think of anything else that is needs to be finished for a
userspace release - I think that covers all the remaining xfstests
failures I'm seeing on crc enabled filesystems....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

[PATCH V2] xfs_copy: band-aids for CRC filesystems

[Eric Sandeen]

xfs_copy needs a fair bit of work for CRCs because it rewrites
UUIDs by default, but this change will get it working properly
with the "-d" (duplicate) option which keeps the same UUID.

Accept the the CRC magic valid, change the ASSERT() to an error
message and exit more gracefully, and don't
even get started if we don't have the '-d' option.

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

diff --git a/copy/xfs_copy.c b/copy/xfs_copy.c
index 9986fbf..f443568 100644
--- a/copy/xfs_copy.c
+++ b/copy/xfs_copy.c
@@ -684,6 +684,16 @@ main(int argc, char **argv)
 	sb = &mbuf.m_sb;
 	libxfs_sb_from_disk(sb, XFS_BUF_TO_SBP(sbp));
 
+	/*
+	 * For now, V5 superblock filesystems are not supported without -d;
+	 * we do not have the infrastructure yet to fix CRCs when a new UUID
+	 * is generated.
+	 */
+	if (xfs_sb_version_hascrc(sb) && !duplicate) {
+		do_log(_("%s: Cannot yet copy V5 fs without '-d'\n"), progname);
+		exit(1);
+	}
+
 	mp = libxfs_mount(&mbuf, sb, xargs.ddev, xargs.logdev, xargs.rtdev, 0);
 	if (mp == NULL) {
 		do_log(_("%s: %s filesystem failed to initialize\n"
@@ -957,7 +967,13 @@ main(int argc, char **argv)
 				 ((char *)btree_buf.data +
 				  pos - btree_buf.position);
 
-			ASSERT(be32_to_cpu(block->bb_magic) == XFS_ABTB_MAGIC);
+			if (be32_to_cpu(block->bb_magic) !=
+			    (xfs_sb_version_hascrc(&mp->m_sb) ?
+			     XFS_ABTB_CRC_MAGIC : XFS_ABTB_MAGIC)) {
+				do_log(_("Bad btree magic 0x%x\n"),
+				        be32_to_cpu(block->bb_magic));
+				exit(1);
+			}
 
 			if (be16_to_cpu(block->bb_level) == 0)
 				break;


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

Re: [PATCH V2] xfs_copy: band-aids for CRC filesystems

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

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