Btrfs computes checksums for all pieces of data and metadata that is stored on disk. This allows Btrfs to detect any corruptions that may happen. If DUP or RAID profiles are used then Btrfs will automatically repair the error.
The default is crc32c which is very fast. One problem with small checksums (digest size) is that the likelihood of a collision is high. A collision means that the two different sets of data computes to the same checksum. Btrfs offers several more modern checksums that provide stronger protection against collisions or malintent alterations.
|CRC32C||32bit||fast, weak, default, CPU support, backward compatible|
|XXHASH||64bit||fast, weak, good on modern CPUs|
|SHA256||256bit||slow, strong, FIPS certified, CPU support|
|BLAKE2B||256bit||slow, strong, good on 64bit architectures|
|Only crc32c is supported before Linux kernel 5.5|
mkfs.btrfs[edit | edit source]
You have to decide what checksum to use when you create the filesystem.
mkfs.btrfs --csum xxhash
Se the mkfs.btrfs man-page for detailed usage.
SMHasher[edit | edit source]
Generally, stronger algorithms are slower than weak ones. You can use SMHasher to benchmark your computer. For example on AMD Ryzens, xxhash64 is faster than crc32c.
Example on an AMD Athlon 3000G (2 cores, 4 threads, 3GHz)
# ./SMHasher --test=Speed <hash>
xxhash64: 11397 MiB/sec crc32_pclmul: 6661 MiB/sec
Note that the difference is generally smaller due to how checksums integrates with the filesystem. You should benchmark your specific workload to determine the impact. Some CPUs and systems have hardware acceleration support.