On Thu, Jun 23, 2016 at 05:37:09PM -0600, Chris Murphy wrote:
> > I expect that parity is in this data block group, and therefore is
> > checksummed the same as any other data in that block group.
>
> This appears to be wrong. Comparing the same file, one file only, one
> two new Btrfs volumes, one volume single, one volume raid5, I get a
> single csum tree entry:
>
> raid5
> item 0 key (EXTENT_CSUM EXTENT_CSUM 12009865216) itemoff 16155 itemsize 128
> extent csum item
>
> single
>
> item 0 key (EXTENT_CSUM EXTENT_CSUM 2168717312) itemoff 16155 itemsize 128
> extent csum item
>
> They're both the same size. They both contain the same data. So it
> looks like parity is not separately checksummed.
I'm inclined to agree because I didn't find any code that *writes* parity
csums...but if there are no parity csums, what does this code do?
scrub.c:
static noinline_for_stack int scrub_raid56_parity(struct scrub_ctx *sctx,
[...]
ret = btrfs_lookup_csums_range(csum_root,
extent_logical,
extent_logical + extent_len - 1,
&sctx->csum_list, 1);
if (ret)
goto out;
ret = scrub_extent_for_parity(sparity, extent_logical,
extent_len,
extent_physical,
extent_dev, flags,
generation,
extent_mirror_num);
Attachment:
signature.asc
Description: Digital signature
