On Fri, Jun 24, 2016 at 10:52:53AM -0600, Chris Murphy wrote: > On Fri, Jun 24, 2016 at 2:50 AM, Hugo Mills <h...@carfax.org.uk> wrote: > > > Checksums are not parity, correct. However, every data block > > (including, I think, the parity) is checksummed and put into the csum > > tree. > > I don't see how parity is checksummed. It definitely is not in the > csum tree. Two file systems, one raid5, one single, each with a single > identical file:
It isn't -- I was wrong up there, and corrected myself in a later message after investigation. (Although in this case, I regard reality as being at fault ;) ). Hugo. > 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 > > That's the only entry in the csum tree. The raid5 one is not 33.33% > bigger to account for the extra parity being checksummed. > > Now, if parity is used to reconstruction of data, that data *is* > checksummed so if it fails checksum after reconstruction the > information is available to determine it was incorrectly > reconstructed. The notes in btrfs/raid56.c recognize the possibility > of parity corruption and how to handle it. But I think that corruption > is inferred. Maybe the parity csums are in some other metadata item, > but I don't see how it's in the csum tree. > > -- Hugo Mills | Great oxymorons of the world, no. 2: hugo@... carfax.org.uk | Common Sense http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
