Johannes Thumshirn wrote:
This patchset add support for adding new checksum types in BTRFS. Currently BTRFS only supports CRC32C as data and metadata checksum, which is good if you only want to detect errors due to data corruption in hardware. But CRC32C isn't able cover other use-cases like de-duplication or cryptographically save data integrity guarantees. The following properties made SHA-256 interesting for these use-cases: - Still considered cryptographically sound - Reasonably well understood by the security industry - Result fits into the 32Byte/256Bit we have for the checksum in the on-disk format - Small enough collision space to make it feasible for data de-duplication - Fast enough to calculate and offloadable to crypto hardware via the kernel's crypto_shash framework. The patchset also provides mechanisms for plumbing in different hash algorithms relatively easy.
Howdy , being just a regular user I am in fact a bit concerned about what happens to my delicious (it's butter after all) filesystems if I happen to move disks between servers. Let's say server A has a filesystem that support checksum type_1 and type_2 while server B only supports type_1.
If the filesystem only has checksum of type_2 stored I would assume that server B won't be able to read the data.
Ignoring checksums will kind of make BTRFS pointless, but I think this is a good reason to consider adding a 'ignore-checksum' mount option - at least it could make the data readable (RO) in a pinch.
....actually since you could always fall back to the original crc32c then perhaps RO might not even be needed at all ?!
I openly admit to NOT having read the patchset, so feel free to ignore my comment if this has already been discussed...
