Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Mark many functions as static, and remove any resulting dead code.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
cmds-recieve.c & cmds-send.c seem to have weird wrappers and
indirections, and "groups" of commands which have only
one member, which are never referenced in the code.
I think these can be removed.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
