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. 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. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
