On Tue, Nov 25, 2014 at 05:39:05PM +0100, 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.
That's a good point. > > 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. Yes, but breaking it into meta_csum_type and data_csum_type will need a imcompat flag. > > > 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 I thought about this before, if we enable this, a few cases need to be dealt with(at least), 1. convert file data's csum from one algorithm to another 2. to make different checksum length co-exist, we can either use different key.type for different algorithms, or pack checksum into a new structure that has algorithm types(and length). 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
