All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Behrens <sbehrens@giantdisaster.de>
To: David Sterba <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: image: handle superblocks correctly on fs with big blocks
Date: Tue, 07 May 2013 10:44:05 +0200	[thread overview]
Message-ID: <5188BED5.3040201@giantdisaster.de> (raw)
In-Reply-To: <1367874680-9502-1-git-send-email-dsterba@suse.cz>

On Mon,  6 May 2013 23:11:20 +0200, David Sterba wrote:
> Superblock is always 4k, but metadata blocks may be larger. We have to
> use the appropriate block size when doing checksums, otherwise they're
> wrong.
> 
> Signed-off-by: David Sterba <dsterba@suse.cz>
> ---
>  btrfs-image.c | 27 +++++++++++++++++++++++----
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/btrfs-image.c b/btrfs-image.c
> index 188291c..dca7a28 100644
> --- a/btrfs-image.c
> +++ b/btrfs-image.c
> @@ -469,6 +469,16 @@ static int read_data_extent(struct metadump_struct *md,
>  	return 0;
>  }
>  
> +static int is_sb_offset(u64 offset) {
> +	switch (offset) {
> +		case 65536:
> +		case 67108864:
> +		case 274877906944:

Using btrfs_sb_offset() and an if statement would produce the same code
and would be more readable.
Additionally, the last huge number will cause a warning on 32-bit
systems, I assume.


> +			return 1;
> +	}
> +	return 0;
> +}
> +
>  static int flush_pending(struct metadump_struct *md, int done)
>  {
>  	struct async_work *async = NULL;
> @@ -506,7 +516,16 @@ static int flush_pending(struct metadump_struct *md, int done)
>  		}
>  
>  		while (!md->data && size > 0) {
> -			eb = read_tree_block(md->root, start, blocksize, 0);
> +			/*
> +			 * We must differentiate between superblock and
> +			 * metadata on filesystems with blocksize > 4k,
> +			 * otherwise the checksum fails for superblock
> +			 */
> +			int bs = blocksize;
> +
> +			if (is_sb_offset(start))
> +				bs = BTRFS_SUPER_INFO_SIZE;
> +			eb = read_tree_block(md->root, start, bs, 0);
>  			if (!eb) {
>  				free(async->buffer);
>  				free(async);
> @@ -516,9 +535,9 @@ static int flush_pending(struct metadump_struct *md, int done)
>  			}
>  			copy_buffer(async->buffer + offset, eb);
>  			free_extent_buffer(eb);
> -			start += blocksize;
> -			offset += blocksize;
> -			size -= blocksize;
> +			start += bs;
> +			offset += bs;
> +			size -= bs;
>  		}
>  
>  		md->pending_start = (u64)-1;
> 


  reply	other threads:[~2013-05-07  8:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06 21:11 [PATCH] btrfs-progs: image: handle superblocks correctly on fs with big blocks David Sterba
2013-05-07  8:44 ` Stefan Behrens [this message]
2013-05-10 11:20   ` David Sterba
2013-05-10 14:26     ` Stefan Behrens
2013-05-10 15:03       ` David Sterba
2013-05-10 15:08 ` Chris Mason

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=5188BED5.3040201@giantdisaster.de \
    --to=sbehrens@giantdisaster.de \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@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 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.