public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs_copy: fix up initial sb buffer read on CRC fs
Date: Tue, 21 Jul 2015 08:31:58 -0400	[thread overview]
Message-ID: <20150721123158.GF23013@bfoster.bfoster> (raw)
In-Reply-To: <55A7F5EE.5000500@sandeen.net>

On Thu, Jul 16, 2015 at 01:20:30PM -0500, Eric Sandeen wrote:
> My prior commit, aaf90a2 xfs_copy: fix copy of hard 4k devices
> causes xfs_copy to emit a CRC error warning when copying a
> CRC filesystem.
> 
> This is because we are now reading the maximum sector size,
> and attempting to verify the CRC based on that (likely incorrect)
> length.
> 
> In xfs_db, we currently just don't verify this read, so it's
> not a problem.  In xfs_copy, we almost certainly want to verify.
> 
> So, first do the maximal read with no verifier; once it's read,
> drop that buffer, and re-read with the proper sector size and
> verifier.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> diff --git a/copy/xfs_copy.c b/copy/xfs_copy.c
> index 44a32e8..fd96e15 100644
> --- a/copy/xfs_copy.c
> +++ b/copy/xfs_copy.c
> @@ -654,11 +654,17 @@ main(int argc, char **argv)
>  
>  	memset(&mbuf, 0, sizeof(xfs_mount_t));
>  	libxfs_buftarg_init(&mbuf, xargs.ddev, xargs.logdev, xargs.rtdev);
> +	/* We don't yet know the sector size, so read maximal size */
>  	sbp = libxfs_readbuf(mbuf.m_ddev_targp, XFS_SB_DADDR,
> -			     1 << (XFS_MAX_SECTORSIZE_LOG - BBSHIFT),
> -			     0, &xfs_sb_buf_ops);
> +			     1 << (XFS_MAX_SECTORSIZE_LOG - BBSHIFT), 0, NULL);
>  	sb = &mbuf.m_sb;
>  	libxfs_sb_from_disk(sb, XFS_BUF_TO_SBP(sbp));
> +	/* Do it again, now with proper length and verifier */
> +	libxfs_putbuf(sbp);
> +	libxfs_purgebuf(sbp);

Why the purge? On a quick look, it looks like the buffer cache code
would handle this if the buffer size changes.

Hmm, is it to ensure the verification occurs if the buffer size doesn't
actually change? If so, I'd suggest to enhance the comment. :)

Brian

> +	sbp = libxfs_readbuf(mbuf.m_ddev_targp, XFS_SB_DADDR,
> +			     1 << (sb->sb_sectlog - BBSHIFT),
> +			     0, &xfs_sb_buf_ops);
>  
>  	/*
>  	 * For now, V5 superblock filesystems are not supported without -d;
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

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

  reply	other threads:[~2015-07-21 12:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16 18:20 [PATCH] xfs_copy: fix up initial sb buffer read on CRC fs Eric Sandeen
2015-07-21 12:31 ` Brian Foster [this message]
2015-07-21 15:11   ` Eric Sandeen
2015-07-21 15:45     ` Brian Foster

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=20150721123158.GF23013@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=sandeen@sandeen.net \
    --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