kdave
commented
1 month ago Also mentioned in https://btrfs.readthedocs.io/en/latest/dev/dev-send-stream.html#command-structure "Note: the checksum initial seed is not 0xFFFFFFFF but 0x0. That is a slight mistake and not the recommended way, overlooked when the protocol was implemented. This does not have a big impact though."
I've updated the changelog a bit so it's more descriptive and added link to the stream docs. Patch added to devel, thanks.
The way the CRC32C checksum used for btrfs-send differs from the way it's used elsewhere in btrfs. Without making the distinction, it's easy to make the flawed assumption that CRC32C always refers to the same, and end up with code that produces the wrong checksums.
This small note should guide the reader to the right function.
The best notes on the protocol I found are here:
https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Design_notes_on_Send/Receive.html
Reading "crc32", I thought it was easy to implement. Long story short I learned a lot more about CRC than I wanted. After bouncing around between different implementations claiming to be "the BTRFS one", I found that there are two ways to use CRC32C in btrfs.
Debugging a hash function is a trial-and-error affair, because you can hardly deduce which input was wrong, so you can never be sure if you actually made a subtle mistake or used the wrong algorithm whatsoever. So with the next person in mind, this commit reveals the mystery in the docs: yes, it's the same algorithm. Those two parameters are the ones which differ.
Rust code describing the algorithm for the crc crate that worked for me:
(it's a slight variation on the one used in ISCSI)