On Mon, Nov 24, 2014 at 08:23:25AM +0000, Holger Hoffstätte wrote: > 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.
Haven't see that so far, but here is a link for crc32c hash collision in btrfs, http://lwn.net/Articles/529077/, it's not data checksum though, btrfs's DIR_ITEM also use crc32c hash, if those happen to be data blocks, something interesting will happen. > > Would there be room for a compromise with e.g. 128 bits? Yeah, we're good if it's not larger than 256 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"). Urr, my bad, I've made it locally but didn't 'git add' them. thanks, -liubo -- 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
