btrfs-progs: docs: clarify btrfs-send checksum

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

The crc32c might be used in two meanings and this could be confusing
when implementing the send stream protocol.

Rust code describing the algorithm for the crc crate that worked for me:

pub const CRC_32_BTRFS_SEND: crc::Algorithm<u32> = crc::Algorithm {
	width: 32, poly: 0x1edc6f41, init: 0, refin: true, refout: true,
	xorout: 0, check: 0xe3069283, residue: 0xb798b438
};

(it's a slight variation on the one used in ISCSI)

Note: Documentation/dev/dev-send-stream.rst briefly mentions that

Pull-request: #794
Author: rhn <gihu.rhn@porcupinefactory.org>
[ rephrase changelog and copy text from pull request and add link to
  developer documentation of the send stream ]
Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
rhn 2024-05-11 07:46:58 +00:00 committed by David Sterba
parent 28eb473c51
commit 07b8c74bc8

View File

@ -20,5 +20,6 @@ The stream is a sequence of encoded commands that change e.g. file metadata
(owner, permissions, extended attributes), data extents (create, clone,
truncate), whole file operations (rename, delete). The stream can be sent over
network, piped directly to the receive command or saved to a file. Each command
in the stream is protected by a CRC32C checksum. See :doc:`btrfs-send`
and :doc:`btrfs-receive` for more.
in the stream is protected by a CRC32C checksum, with 0 as the initial value
and no inversion. See :doc:`btrfs-send` and :doc:`btrfs-receive` for more,
for protocol description :doc:`dev-send-stream`.