path: root/send-stream.c
Commit message (Collapse)AuthorAge
* btrfs-progs: fix compiler warningChristian Hesse2014-11-07
| | | | | | | | | | | gcc 4.9.0 gives warnings about possibly uninitialized values when compiling with function inlining and optimization level two enabled (CFLAGS="-finline-functions -O2"). Initializing the values fixes the warning. Hope this is correct. Signed-off-by: Christian Hesse <> Signed-off-by: David Sterba <>
* btrfs-progs: fix unaligned loads in receiveZach Brown2014-08-22
| | | | | | | | | | | | | | | | | A user reported corruption after receiving subvolumes. Turning up the logging during the receive showed that the commands and string attributes were being received correctly but the u64 attrbutes were sometimes corrupted by having variable number of low order bytes introduced. It turned out they were on a platform that corrupts unaligned userspace loads. Loading the u64s from the unaligned pointers into the received command stream with get_unaligned() fixed the problem. Reported-By: Klaus Holler <> Tested-By: Klaus Holler <> Signed-off-by: Zach Brown <> Signed-off-by: David Sterba <>
* Btrfs-progs: receive, allow to continue after errors happenFilipe David Borba Manana2014-08-22
| | | | | | | | | | | | | | | | | | | | Due to either bugs in send (kernel) that generate a command against a wrong path for example, or transient errors on the receiving side, we stopped processing the send stream immediately and exited with an error. It's often desirable to continue processing the send stream even if an error happens while processing a single command from the send stream. This change just adds a --max-errors <N> parameter, whose default value is 1 (preserving current behaviour), that allows to tolerate N errors before stopping. A value of 0 means to never stop no matter how many errors we get into while processing the send stream. Regardless of its value, errors are always printed to stderr when they happen, just like before this change. Signed-off-by: Filipe David Borba Manana <> Signed-off-by: David Sterba <>
* 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 <>