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>
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 <mail@eworm.de>
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>
Since this patch:
btrfs-progs: move the check_argc_* functions into utils.c
All tools including the independent tools(e.g. btrfs-image, btrfs-convert)
can share the convenience of the check_argc_* functions, so this patch
adopt the argc check functions globally.
Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
find_good_parent() uses assert to deal with the problem that clone
source's parent can't be found.
But in fact the assert is somewhat overkilled since subvol_uuid_search()
has enough error messages for debug and caller of find_good_parent() can
handle the problems in find_good_parent(), so the assert can be removed
without any problem.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Threads always use default attributes in all tools, so pthread
attribute objects and their initializations are of no use. Just pass
NULL as attr attribute to pthread_create for default attributes.
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>
Move find_mount_root to utils.[ch] for general use.
Signed-off-by: Qu Wenruo <quwenruo@cn.fuijitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
- send accepts multiple subvolumes
- add missing option -e to man
- minor man formatting fix
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Steps to reproduce:
# mkfs.btrfs -f /dev/sda
# mount /dev/sda /mnt
# btrfs subvolume create /mnt/foo
# umount /mnt
# mount -o subvol=foo /dev/sda /mnt
# btrfs sub snapshot -r /mnt /mnt/snap
# btrfs send /mnt/snap > /dev/null
We will fail to send '/mnt/snap',this is because btrfs send try to
open '/mnt/snap' by btrfs internal subvolume path 'foo/snap' rather
than relative path based on mounted point, this will return us 'no
such file or directory',this is not right, fix it.
Reported-by: Thomas Scheiblauer <tom@sharkbay.at>
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>
getmntent should be used in context of *mntent functions, though
fopen/fclose works.
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
find_mount_root() tries to test for realpath() failure, but
tests the wrong value. Fix it.
Resolves-Coverity-CID: 1125940
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
I hit a segfault when deleting a subvolume with very long name(>4096),
it's because cmd_subvol_delete() calls strdup() and passes NULL as
argument, which is returned by realpath(3).
I used the following script to reproduce
#!/bin/bash
mnt=$1
i=1
path=$mnt/subvol_$i
# Create very deep subvolumes
while btrfs sub create $path;do
((i++))
path="$path/subvol_$i"
done
last_vol=$(dirname $path)
dir=$(dirname $last_vol)
vol=$(basename $last_vol)
# Try to delete tha last one, this would get segfault
pushd $dir
btrfs sub delete $vol
popd
Fix it by checking return value of realpath(3), also fix the one in
find_mount_root().
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Check for fopen() failure. This shows up in static analysis as a
possible null pointer derference.
Signed-off-by: Zach Brown <zab@redhat.com>
Laughed-at-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
If btrfs send return failure, we return 1，otherwise 0 will be returned.
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>
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>
Update the usage strings of some cmds to keep the them consistent with
the source.
Also some minor changes are done to fit the man page syntax.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
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>
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 <sbehrens@giantdisaster.de>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
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 <sbehrens@giantdisaster.de>
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>
/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 <sbehrens@giantdisaster.de>
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 <sandeen@redhat.com>
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 <anand.jain@oracle.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>
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 <chenyang.fnst@cn.fujitsu.com>
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 <list.btrfs@jan-o-sch.net>
Signed-off-by: Cheng Yang <chenyang.fnst@cn.fujitsu.com>
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 <list.btrfs@jan-o-sch.net>
Likely not strictly needed but I noticed valgrind complaining about
uninitialised memory in the ioctl call.
Signed-off-by: Arvin Schnell <aschnell@suse.de>
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 <viric@viric.name>
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>
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 <miaox@cn.fujitsu.com>
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 <list.btrfs@jan-o-sch.net>
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 <chris.mason@fusionio.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>
Dimitri John Ledkov
David Sterba
Christian Hesse
Qu Wenruo
Gui Hecheng
Rakesh Pandit
Wang Shilong
Anand Jain
Eric Sandeen
Eryu Guan
Zach Brown
Stefan Behrens
Alex Lyakas
Chen Yang
Jan Schmidt
Arvin Schnell
Lluis Batlle i Rossell
Wade Cline
Miao Xie
Chris Mason
Alexander Block