On Thu, Nov 27, 2014 at 11:52:20AM +0800, Liu Bo wrote: > > 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.
Not necessarily a new bit. If we read the field as-is, see if it's zero we know it's the previous version, otherwise the new one and then set only in-memory fileds for data and metadata. The backward compatibility is fine, old kernels will refuse to mount with csum_type != 0. > > 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 On-line or offline? I'd rather avoid doing that on a mounted filesystem. > 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). Oh right, the mixed sizes of checksums could be a problem and would require a format change (and thus the incompatibility bit). The key.type approach looks better, we'd encode the algorithm type effectively, the item bytes contain only fixed-size checksums. (Here I'm thinking a new BTRFS_EXTENT_CSUM_KEY per checksum type.) OTOH storing the algo type (size is not needed) would add overhead per-checksum (probably only a single byte but still). -- 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
