path: root/cmds-send.c
Commit message (Collapse)AuthorAge
* Btrfs-progs: use UUID tree for send/receiveStefan Behrens2013-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the btrfs send/receive commands to use the UUID tree to map UUIDs to subvolumes, and to use the root tree to map subvolume IDs to paths. Now these tools start fast and are independent on the number of subvolules/snapshot that exist. Before this commit, mapping UUIDs to subvolume IDs was an operation with a high effort. The algorithm even had quadratic effort (based on the number of existing subvolumes). E.g. with 15,000 subvolumes it took much more than 5 minutes on a state of the art XEON CPU to start btrfs send or receive before these tools were able to send or receive the first byte). Even linear effort instead of the current quadratic effort would be too much since it would be a waste. And these data structures to allow mapping UUIDs to subvolume IDs had been created every time a btrfs send/receive instance was started. It is much more efficient to maintain a searchable persistent data structure in the filesystem, one that is updated whenever a subvolume/snapshot is created and deleted, and when the received subvolume UUID is set by the btrfs-receive tool. Therefore kernel code was added that is able to maintain data structures in the filesystem that allow to quickly search for a given UUID and to retrieve data that is assigned to this UUID, like which subvolume ID is related to this UUID. Signed-off-by: Stefan Behrens <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* Btrfs-progs: add send option for using new end-cmd semanticStefan Behrens2013-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a command line option to enable sending streams which make use of the new end-cmd semantic if multiple snapshots are sent back-to-back. The goal is to use the <end cmd> as an indication to stop reading the input stream. So far, the receiver could only use EOF to recognize the end. If the new command line option '-e' is set, this commit requires a kernel which is able to support the new flags in the send ioctl. New bits in the flags of the send ioctl will be set which cause EINVAL on old kernels. However, if the option '-e' is not set, it works with old and new kernels without any errors or any changed behavior. This used to be the encoding (with 2 snapshots in this example): <stream header> + <sequence of commands> + <end cmd> + <stream header> + <sequence of commands> + <end cmd> + EOF The new format (if the two new flags are used) is this one: <stream header> + <sequence of commands> + <sequence of commands> + <end cmd> 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. Also note that the kernel interface was changed in a way that is backward compatible to old btrfs-progs tools. You set one or two bits in the flags field of the ioctl to enable the new behavior. Old tools set these flags to zero, thus getting exactly the same as they got with older kernels. And this is exactly what happens if the new '-e' option is not set, the new bits in the flags are not set and thus old kernels and new kernels are both supported. So what is the benefit of this change? The goal 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 <> Signed-off-by: David Sterba <> Signed-off-by: Chris Mason <>
* Btrfs-progs: btrfs-send: free used memory and close fdsStefan Behrens2013-04-23
| | | | | | | | Not important at all since exit() is called afterwards and this is not part of the library. It just makes valgrind happy and thus allows to search for real flaws. Signed-off-by: Stefan Behrens <>
* btrfs-progs: Fix the receive code pathingAlex Lyakas2013-04-23
| | | | | | | | | | | | | The receive code was not distinguishing properly between the mount root and the directory to create the received subvolume in. Also make sure the find_mount_root reports an error if it cannot find a match at all. Reported-by: Robert Buhren <> Reported-by: Rory Campbell-Lange <> Reported-by: Stefan Priebe - Profihost AG <> Signed-off-by: Alex Lyakas <> Signed-off-by: Stefan Behrens <>
* Btrfs-progs: cleanup subvol_uuid_search memory in btrfs send/receiveStefan Behrens2013-04-23
| | | | | | Call the cleanup function that was introduced with the other commit. Signed-off-by: Stefan Behrens <>
* Btrfs-progs: close file descriptor in cmds-send.cStefan Behrens2013-04-23
| | | | | | valgrind found this very obvious issue. Signed-off-by: Stefan Behrens <>
* Btrfs-progs: Use /proc/mounts instead of /etc/mtabStefan Behrens2013-04-09
| | | | | | | | /etc/mtab is not working correctly in situations where multiple mount namespaces are used. Use /proc/mounts instead like the rest of the code is doing it. Signed-off-by: Stefan Behrens <>
* btrfs-progs: initialize pipefd[] for error pathEric Sandeen2013-02-05
| | | | | | | | | | | Several goto out; paths will end up doing i.e. if (pipefd[0]) close(pipefd[0]); but we get there with uninitialized values in many cases. Signed-off-by: Eric Sandeen <>
* Btrfs-progs: make get_subvol_name non cmds-send specificAnand Jain2013-02-01
| | | | | | | | get_subvol_name can be used other than the just with in cmds-send.c so this patch will make it possible with out changing the original intentions. Signed-off-by: Anand Jain <>
* Btrfs-progs: Complete the help information of btrfs send/receiveChen Yang2013-02-01
| | | | | | | | | | When typing command "btrfs send --help" or "btrfs receive --help", the help information of the commands is incomplete, which only shows a short usage. This patch helps to display the complete infomation of the commands. Signed-off-by: Cheng Yang <>
* Btrfs-prog/send: fix wrong dump_fd check in cmd_send_start()Chen Yang2013-01-31
| | | | | | | | In cmd_send_start(), there is a check to make sure dump_fd is not a tty before parsing command options. So if we use the option "-f file", it doesn't work for the dump_fd has not been created. So fix it. Signed-off-by: Cheng Yang <>
* Btrfs-prog/send: fix wrong best-parent assignment in, find_good_parent()Chen Yang2013-01-25
| | | | | | | | | We use find_good_parent() to look for a suit snapshot in the clone source snapshots as the parent, not the source subvolume of the snapshot which is about to be sent. fix it Reviewed-by: Jan Schmidt <> Signed-off-by: Cheng Yang <>
* Btrfs-progs: correcting misnamed parameter options for btrfs sendJan Schmidt2013-01-21
| | | | | | | | | | | | Unfortunately, the command line options for btrfs send were misnamed. The -i option should not be used to give "clone sources", we'll be using -c instead. Compatibily note: -i option was broken anyway, which makes it less critical renaming it. For potential users of the old option style, we emit a fatal warning if the -i option is used. Signed-off-by: Jan Schmidt <>
* btrfs-progs: initialize data before send ioctlArvin Schnell2013-01-21
| | | | | | | Likely not strictly needed but I noticed valgrind complaining about uninitialised memory in the ioctl call. Signed-off-by: Arvin Schnell <>
* btrfs-progs: Fix getopt on arm platformsLluis Batlle i Rossell2013-01-17
| | | | | | | There, 'char' is unsigned, so once assigned '-1' from getopt, it gets the value 255. Then, it compared to '-1' gives false. Signed-off-by: Lluis Batlle i Rossell <>
* btrfs-progs: do not send stream into a terminalDavid Sterba2013-01-17
| | | | Signed-off-by: David Sterba <>
* Btrfs-progs: Fix compiler warnings on PPC64Wade Cline2013-01-17
| | | | | | | | | | | | | | | | The kernel uses unsigned long long for u64, but PPC64 uses unsigned long by default. This results in compilation warnings such as: print-tree.c:333: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'u64' To fix this, the macro __KERNEL__ needs to be defined before including the file <asm/types.h>. This can be done by defining the macro in "kerncompat.h" and making it the first included file in the relevant header files; this fixes the compiler warnings on PPC64. Reviewed-by: David Sterba <> Signed-off-by: Wade Cline <>
* Btrfs-progs: fix several complie warningMiao Xie2012-10-04
| | | | | | | | | | | | | | This patch fixed the following warning: cmds-send.c:464:6: warning: ‘ret' may be used uninitialized in this function [-Wuninitialized] crc32c.c:121:1: warning: control reaches end of non-void function [-Wreturn-type] send-utils.c:69:11: warning: ‘comp' may be used uninitialized in this function [-Wuninitialized] send-utils.c:126:6: warning: ‘comp' may be used uninitialized in this function [-Wuninitialized] send-utils.c:99:22: warning: ‘entry' may be used uninitialized in this function [-Wuninitialized] btrfs.c:261:2: warning: implicit declaration of function ‘crc32c_optimization_init' [-Wimplicit-function-declaration] btrfs.c:105:2: warning: ‘cmd' may be used uninitialized in this function [-Wuninitialized] restore.c:435:12: warning: ignoring return value of ‘ftruncate', declared with attribute warn_unused_result [-Wunused-result] Signed-off-by: Miao Xie <>
* Btrfs-progs: replace find_mount_root from send codeJan Schmidt2012-08-20
| | | | | | | | | | | find_mount_root had the problem that it tried to conclude from a file system path to a mount point, taking the fsid as an indicator. This only works if no two subvolumes (sharing the same btrfs fsid) are mounted in the same hierarchy. Now instead, we're parsing /etc/mtab and look for the longest match. Signed-off-by: Jan Schmidt <>
* Allow relative paths for btrfs sendChris Mason2012-08-09
| | | | | | | | The initial btrfs send code was easily confused by relative paths and by anything that wasn't in the root of the FS. This fixes it to take relative paths. Signed-off-by: Chris Mason <>
* 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 <>