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

[Alex Elsayed <eternaleye@gmail.com>]

David Sterba wrote:

> On Mon, Nov 24, 2014 at 01:23:05PM +0800, Liu Bo 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
> 
> There's already some good feedback so I'll try to cover what hasn't been
> mentioned yet.
> 
> I think it's better to separate the preparatory works from adding the
> algorithm itself. The former can be merged (and tested) independently.
> 
> There are several checksum algorithms that trade off speed and strength
> so we may want to support more than just sha256. Easy to add but I'd
> rather see them added in all at once than one by one.

Why not just use the kernel crypto API? Then the user can just specify any 
hash the kernel supports.

> Another question is if we'd like to use different checksum for data and
> metadata. This would not cost any format change if we use the 2 bytes in
> super block csum_type.

Mmm, that might be a good reason - although maybe store an entry in some 
tree of the full crypto api spec, and have a special value of one byte 
meaning "crypto API" and the other byte counts how many bytes the csum is.

> Optional/crazy/format change stuff:
> 
> * per-file checksum algorithm - unlike compression, the whole file would
>   have to use the same csum algo
>   reflink would work iff the algos match
>   snapshotting is unaffected
> 
> * per-subvolume checksum algorithm - specify the csum type at creation
>   time, or afterwards unless it's modified
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
W