On Mon, 24 Nov 2014 13:23:05 +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.
I'm curious - did you see actual cases where this happened, i.e. a corrupt
block that would pass crc32 validation? I know some high-integrity use
cases require a stronger algorithm - just wondering.
Would there be room for a compromise with e.g. 128 bits?
> Users can choose sha256 from mkfs.btrfs via
>
> $ mkfs.btrfs -C 256 /device
Not sure how others feel about this, but it's probably easier for
sysadmins to specify the algorithm by name from the set of supported
ones, similar to how ssh does it ("ssh -C arcfour256").
cheers
Holger
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
