Re: [RFC PATCH] Btrfs: add sha256 checksum option

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option
From: Hugo Mills <hugo@carfax.org.uk>
To: Chris Mason <clm@fb.com>
Date: 2014年11月25日 04:58
> On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
>> On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo <bo.li.liu@oracle.com> wrote:
>>> This brings a strong-but-slow checksum algorithm, sha256.
>>>
>>> Actually btrfs used sha256 at the early time, but then moved to
>>> crc32c for
>>> performance purposes.
>>>
>>> As crc32c is sort of weak due to its hash collision issue, we need
>>> a stronger
>>> algorithm as an alternative.
>>>
>>> Users can choose sha256 from mkfs.btrfs via
>>>
>>> $ mkfs.btrfs -C 256 /device
>> Agree with others about -C 256...-C sha256 is only three letters more ;)
>>
>> What's the target for this mode?  Are we trying to find evil people
>> scribbling on the drive, or are we trying to find bad hardware?
>     You're going to need a hell of a lot more infrastructure to deal
> with the first of those two cases. If someone can write arbitrary data
> to your storage without going through the filesystem, you've already
> lost the game.
>
>     I don't know what the stats are like for random error detection
> (probably just what you'd expect in the naive case -- 1/2^n chance of
> failing to detect an error for an n-bit hash). More bits likely are
> better for that, but how much CPU time do you want to burn on it?
Agree with this, sha256's extra CPU usage seems not so worthy.

About the csum algorithm, personally I prefer algorithm with better 
error detection,
not only the integration about the whole data, but the range where the 
error lies in.

If btrfs can know, for example which 4K or 2K block the error lies in, 
it can drops only the range of data,
not the whole tree block, which can do great help for later btrfsck things.

In this point of view, 4 crc32 for 16K leaf/node (1 crc32 for 4K) may be 
more productive than single sha256.

Thanks,
Qu
>
>     I could see this possibly being useful for having fewer false
> positives when using the inbuilt checksums for purposes of dedup.
>
>     Hugo.