summaryrefslogtreecommitdiff
path: root/cmds-receive.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 <sbehrens@giantdisaster.de> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* 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 <robert@robertbuhren.de> Reported-by: Rory Campbell-Lange <rory@campbell-lange.net> Reported-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag> Signed-off-by: Alex Lyakas <alex.btrfs@zadarastorage.com> Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: allow to receive to relative directoriesStefan Behrens2013-04-23
| | | | Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: Fix that BTRFS_FSID_SIZE is used instead of BTRFS_UUID_SIZEStefan Behrens2013-04-23
| | | | | | Both are 16 but it's wrong anyway to use FSID_SIZE for UUIDs. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* 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 <sbehrens@giantdisaster.de>
* Btrfs-progs: small parent_subvol cleanup for cmds-receive.cStefan Behrens2013-04-23
| | | | | | parent_subvol is local to process_snapshot() and not needed outside. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: Set the root-id for received subvols in btrfs receiveStefan Behrens2013-04-23
| | | | | | | | | When an entry was added to the subvol search tree, the root_id was always 0 (not set at all) and therefore only the first one was added, all the others had been ignored. This commit sets the root_id before the entry is added. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: btrfs-receive: different levels (amount) of debug outputStefan Behrens2013-04-23
| | | | | | | | | There used to be 2 levels of verbose output, now there are 3: - None at all (no -v option given). - Some information about received snapshots / subvolumes (-v option). - Each received command is printed (-vv option). Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: free memory and close file descriptor in btrfs receiveStefan Behrens2013-04-23
| | | | | | | Nothing really important since this is not part of the library and at the end exit() is called. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* 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 <sbehrens@giantdisaster.de>
* btrfs-progs: fix overflows of ioctl name argsEric Sandeen2013-02-05
| | | | | | | | | 3 places where we copy pathnames into ioctl arguments were not limited to the destination name size, and could overflow. Use the new strncpy_null() macro to make this safe. Signed-off-by: Eric Sandeen <sandeen@redhat.com>
* btrfs-progs: remove unused info_fdZach Brown2013-02-05
| | | | | | finish_subvol() initializes and tests info_fd but it is never used. Signed-off-by: Zach Brown <zab@redhat.com>
* 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 <chenyang.fnst@cn.fujitsu.com>
* Btrfs-progs: correct btrfs receive usage stringUlrik2013-01-21
| | | | | | | | Fix the usage string to specify the correct '-f' option for input file, not '-i'. Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com> Signed-off-by: Gene Czarcinski <gene@czarc.net>
* btrfs-progs: Receive: preserve ownership for symlinks, by using 'lchown'Alex Lyakas2013-01-17
| | | | Signed-off-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
* 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 <dsterba@suse.cz> Signed-off-by: Wade Cline <clinew@linux.vnet.ibm.com>
* Btrfs-progs: add btrfs send/receive commandsAlexander Block2012-07-26
Add user space commands for btrfs send/receive. Signed-off-by: Alexander Block <ablock84@googlemail.com> Reviewed-by: David Sterba <dave@jikos.cz> Reviewed-by: Arne Jansen <sensille@gmx.net> Reviewed-by: Jan Schmidt <list.btrfs@jan-o-sch.net> Reviewed-by: Alex Lyakas <alex.bolshoy.btrfs@gmail.com>