Timeline for Why use strong checksums to detect random errors in a filesystem like btrfs?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 2, 2023 at 9:47 | comment | added | Joachim Wagner | xxhash comes in 32, 64 and 128 bit variants and including the latter in btrfs is being considered: github.com/kdave/btrfs-progs/issues/548 | |
| Jan 11, 2023 at 10:47 | comment | added | blubberdiblub | This answer is either a misunderstanding (or incomplete understanding) of the Birthday Paradox or simply fails to realize that it doesn't apply to the question asked. The Birthday Paradox is about the (for some people) counter-intuitive increase of the probability of collisions among multiple items when the amount of items increases. It would only apply if you use the in-filesystem checksum to look for file duplicates or use that checksum to identify the file itself against some list or database (which, to my knowledge, nobody does) and the question was not about that anyways. | |
| Dec 3, 2020 at 12:47 | vote | accept | kjdf | ||
| Dec 1, 2020 at 16:46 | comment | added | kjdf | user253751, and cryptographically secure algorithms are designed to be completely different for even the smallest change in the data, so it doesn't make cryptographic algorithms less suitable in that manner. They are only slower to calculate which I believe is the main concern. | |
| Dec 1, 2020 at 13:27 | comment | added | Ger Hobbelt | CRCs were designed to detect n-bit errors (n=1,2,...) in communications. Disk failures (spinning ones, not SSDs) are generally of the track loss type (physical damage) or sector loss, both of which are MANY bits. Crypto hashes are a better solution for these than CRCs. (havent looked at xxhash internals and design criteria so YMMV). | |
| Dec 1, 2020 at 12:53 | comment | added | Criticizing Israel not allowed | Remember that CRC is designed for checking corruption, though, so it has some guarantees: you can guarantee that a single-bit flip will change a CRC, while there's no such guarantee for SHA-1 | |
| Dec 1, 2020 at 11:39 | comment | added | kjdf | What matters is does it collide with itself, not if it collides with other data on the disk | |
| Dec 1, 2020 at 11:22 | comment | added | kjdf | First of all, thank you very much for your reply! on btrfs, xxhash is 64 bits and blake2b is 256 bits. I get the birthday paradox, but in this case that would mean that all blocks are corrupted in the first place which is not the case hopefully (disk is dead). Only a few percentage of the disk may be corrupted and at the same time the randomly corrupted data (not designed by an attacker) must produce the same checksum as the original data at that location. The checksum may of course collide with the checksum of some other data on the disk, but that doesn't matter either (birthday paradox). | |
| Dec 1, 2020 at 4:33 | history | edited | davidbak | CC BY-SA 4.0 |
added 128 characters in body
|
| Dec 1, 2020 at 4:24 | history | answered | davidbak | CC BY-SA 4.0 |