mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
synced 2024-11-26 21:54:31 +08:00
07b8c74bc8
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>
26 lines
1.5 KiB
ReStructuredText
26 lines
1.5 KiB
ReStructuredText
Send/receive
|
|
============
|
|
|
|
Send and receive are complementary features that allow to transfer data from
|
|
one filesystem to another in a streamable format. The send part traverses a
|
|
given read-only subvolume and either creates a full stream representation of
|
|
its data and metadata (*full mode*), or given a set of subvolumes for reference
|
|
it generates a difference relative to that set (*incremental mode*).
|
|
|
|
Receive on the other hand takes the stream and reconstructs a subvolume with
|
|
files and directories equivalent to the filesystem that was used to produce the
|
|
stream. The result is not exactly 1:1, e.g. inode numbers can be different and
|
|
other unique identifiers can be different (like the subvolume UUIDs). The full
|
|
mode starts with an empty subvolume, creates all the files and then turns the
|
|
subvolume to read-only. At this point it could be used as a starting point for a
|
|
future incremental send stream, provided it would be generated from the same
|
|
source subvolume on the other filesystem.
|
|
|
|
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, 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`.
|