path: root/send-stream.c
Commit message (Collapse)AuthorAge
* Btrfs-progs: remove some unused codeStefan Behrens2013-04-23
| | | | Signed-off-by: Stefan Behrens <>
* Btrfs-progs: btrfs-receive optionally honors the end-cmdStefan Behrens2013-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new option is added to btrfs-receive to change the behavior when an <end cmd> is received in the Btrfs send stream. The traditional behavior (which still is the default) is to continue to read the stream until an EOF condition is encountered. If an <end cmd> is received, afterwards either an EOF or a new <stream header> is expected. The new behavior (if the -e option is set on the command line) is to terminate after an <end cmd> is read without the need for an EOF. This allows the stream (e.g. a single TCP stream) to carry additional data or even multiple Btrfs send streams. Old btrfs-send tools used to encode multiple snapshots like this (with 2 snapshots in this example): <stream header> + <sequence of commands> + <end cmd> + <stream header> + <sequence of commands> + <end cmd> + EOF If the new -e option is set, the expected format is like this: <stream header> + <sequence of commands> + <sequence of commands> + <end cmd> The btrfs-send tool is changed in a seperate commit to always use the new format, i.e. to send an <end cmd> only at the end. Note that the currently existing receivers treat <end cmd> only as an indication that a new <stream header> is following. This means, you can just skip the sequence <end cmd> <stream header> without loosing compatibility. As long as an EOF is following, the currently existing receivers handle the new format (if the two new flags are used) exactly as the old one. The goal of changing the semantic of <end cmd> is to be able to use a single stream (one TCP connection) to multiplex a request/response handshake plus Btrfs send streams, all in the same stream. In this case you cannot evaluate an EOF condition as an end of the Btrfs send stream. You need something else, and the <end cmd> is just perfect for this purpose. Signed-off-by: Stefan Behrens <>
* btrfs-progs: Add support for BTRFS_SEND_FLAG_NO_FILE_DATAMark Fasheh2013-02-12
| | | | | | | | | | | The flag and command are synced from kernel to user. Also, this patch adds a callback for the BTRFS_SEND_C_UPDATE_EXTENT in struct btrfs_send_ops. read_and_process_cmd() is updated to decode BTRFS_SEND_C_UPDATE_EXTENT and send the values through the right callback. I did not add a callback definition to cmds-receive.c as that code never uses BTRFS_SEND_FLAG_NO_FILE_DATA. Signed-off-by: Mark Fasheh <>
* Btrfs-progs: add btrfs send/receive commandsAlexander Block2012-07-26
Add user space commands for btrfs send/receive. Signed-off-by: Alexander Block <> Reviewed-by: David Sterba <> Reviewed-by: Arne Jansen <> Reviewed-by: Jan Schmidt <> Reviewed-by: Alex Lyakas <>