Handle only negative values returned by ioctl syscalls, with exception
of the device remove. It returns positive values that are handled later.
Signed-off-by: David Sterba <dsterba@suse.com>
Noticed this while doing some snapshots in a chroot environment
btrfs receive can set root_path to either realmnt, which is passed in from the
command line, or to a heap allocated via find_mount_root in do_receive. We
should only free the later, not the former, as the former results in an invalid
pointer warning from glibc during free.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
- limits.h must be included to pick up PATH_MAX.
- remove double declaration of BTRFS_DISABLE_BACKTRACE
kerncompat.h assumed that if __GLIBC__ was not defined,
it could safely define BTRFS_DISABLE_BACKTRACE, however this can be
defined by the configure script. Added a check to ensure it is not
defined first.
Signed-off-by: Brendan Heading <brendanheading@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The embedded 'path' is a pointera and we can't make it a path buffer due
to API constraints. Use a separate buffer and sto using the unsafe
path_cat interface.
Signed-off-by: David Sterba <dsterba@suse.cz>
Get rid of the allocation. The logic is changed so that a NULL
cur_subvol::path means that no subvolume/snapshot has been found so far.
Signed-off-by: David Sterba <dsterba@suse.cz>
The path bufferes should be PATH_MAX but BTRFS_PATH_NAME_MAX is shorter
due to embedding in 4k aligned structures.
The only reason to use BTRFS_PATH_NAME_MAX is for the respective
structures btrfs_ioctl_vol_args::name.
Signed-off-by: David Sterba <dsterba@suse.cz>
Kind of a big feature of btrfs is being able to have a default subvol. However
the receive code generates the paths to the subvols from the root of the fs,
even in the case of a default subvol. So instead figure out if we're inside of
a subvol, either because we have a different default or we've chroot'ed and are
using -m. Then strip this extra path off of the subvol we find so we can look
up our parent properly. Thanks
Reported-by: Neil Horman <nhorman@redhat.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
In a chroot environment we may not have /proc mounted, which makes btrfs receive
freak out since it wants to know the base directory where are are mounted for
things like clone and such. Give an option to specify where the mountpoint is
in these cases so you can still do a btrfs receive in a chroot. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
[added manpage documentation]
Signed-off-by: David Sterba <dsterba@suse.cz>
Capabilities are cleared after chown, and the btrfs-stream encodes the
CHOWN command after any SET_XATTR command. So the capabilites are not
always preserved.
This could be fixed in kernel to emit the instructions in the right
order, but fix in userspace will make it work for older kernels.
If we see the capabilities among xattrs, cache the value and apply it
again in case it's followed by chown on that file.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=68891
Reported-by: Juan Orti Alcaine <j.orti.alcaine@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
This will fix breakage, when doing chrooted receive with cloned paths
outside main subvolume.
Steps to reproduce:
$ create subvolume
$ create file
$ snapshot to snap1
$ delete file
$ snapshot to snap2
$ reflink file from snap1
$ snapsthot to snap3
$ send full snap1 | receive --chroot
$ send incremental snap2 | receive --chroot
$ send incremental snap3 | receive --chroot
The last step would fail with:
Chroot to /mnt/recvdir
At snapshot snap3
ERROR: failed to open /recvdir/snap1/file. No such file or directory
Signed-off-by: Emil Karlson <jekarlson@gmail.com>
[added reproducer]
Signed-off-by: David Sterba <dsterba@suse.cz>
The chroot action seems important enough to be printed unconditionally
and without the verbose option that prints way too much information.
Signed-off-by: David Sterba <dsterba@suse.cz>
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri Võsandi <lauri.vosandi@gmail.com>
[added long option variant, added docs]
Signed-off-by: David Sterba <dsterba@suse.cz>
glibc 2.10+ (5+ years old) enables all the desired features:
_XOPEN_SOURCE 700, __XOPEN2K8, POSIX_C_SOURCE, DEFAULT_SOURCE; with a
single _GNU_SOURCE define in the makefile alone. For portability to
other libc implementations (e.g. dietlibc) _XOPEN_SOURCE=700 is also
defined.
This also resolves Debian bug report filed by Michael Tautschnig -
"Inconsistent use of _XOPEN_SOURCE results in conflicting
declarations". Whilst I was not able to reproduce the results, the
reported fact is that _XOPEN_SOURCE set to 500 in one set of files
(e.g. cmds-filesystem.c) generates/defines different struct stat from
other files (cmds-replace.c).
This patch thus cleans up all feature defines, and sets them at a
consistent level.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747969
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Fix the following gcc(>4.9) and clang warning:
In file included from cmds-receive.c:24:
In file included from ./kerncompat.h:22:
In file included from /usr/include/stdio.h:27:
/usr/include/features.h:148:3: warning: "_BSD_SOURCE and _SVID_SOURCE
are deprecated, use _DEFAULT_SOURCE" [-W#warnings]
^
1 warning generated.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Fix the lack of description of "--max-erros" option in
both man and command usage of btrfs receive.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
When calling find_mount_root(), caller in fact wants to find the mount
point of *BTRFS*.
So also check ent->fstype in find_mount_root() and do special error
string output in caller.
This will suppress a lot of "Inapproiate ioctl for device" error
message.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
find_mount_root() function in utils.c should not print error string.
Caller should be responsible to print error string.
This patch will remove the only fprintf in find_mount_root() and modify
the caller a little to use strerror() to prompt users.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
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 <fdmanana@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
"close_inode_for_write" always returns 0, so just remove its return
value and remove dead checking in caller.
Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
To be consistent with the other cmds, replace the warning msg
with usage() when send/receive are used without any args.
Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Don't output normal messages into stderr, this make xfstests
filter output easier.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
If we change our default subvolume, btrfs receive will fail to find
subvolume. To fix this problem, we have three ideas:
1.make btrfs snapshot ioctl support passing source subvolume's objectid.
2.when we want to using interval subvolume path, we mount it other place
that use subvolume 5 as its default subvolume.
3.tell the user to mount the toplevel subvol by himself and run
receive
We's better use the third approach because first patch will bother kernel
change and the second approach is not very good for power users. So give this
option to users.
Reported-by: Michael Welsh Duggan <mwd@md5i.com>
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Steps to reproduce:
# mkfs.btrfs -f <dev>
# mount <dev> <mnt>
# mkdir <mnt>/backup
# btrfs sub create <mnt>/subv
# btrfs sub snapshot -r <mnt>/subv <mnt>/snap1
# btrfs sub snapshot -r <mnt>/subv <mnt>/snap2
# btrfs send <mnt>/snap2 -p <mnt>/snap1 -f sent_file
# btrfs receive -f sent_file <mnt>/backup
Above steps will make btrfs receive fails with "ERROR: can not find
parent subvolume", this is because we try to find parent subvolume by
RECEIVED_SUBVOL_KEY,and it will return ENOENT if parent snapshot has not
been sent or it has been deleted. Actually, we can try harder to find
whether parent subvolume exists by searching uuid key.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
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>
