Variable 'p' is not used any more. So, remove it.
Signed-off-by: NTsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: NJosef Bacik <jbacik@fusionio.com>

Two new flags are added to allow omitting the stream header and the
end command for btrfs send streams. This is used in cases where you
send multiple snapshots back-to-back in one stream.

This used to be encoded like this (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.

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.

The summary is:
The format change is driven by the need to send several Btrfs send
streams over a single TCP connections, with the ability for a repeated
request/response handshake in the middle. And this format change does
not break any existing tool, it is completely compatible.

You could compare the old behaviour of the Btrfs send stream to the
one of ftp where you need a seperate request/response channel and
newly opened data transfer channels for each file, while the new
behaviour is more like http using a single stream for everything.
Signed-off-by: NStefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: NJosef Bacik <jbacik@fusionio.com>

When you take a snapshot, punch a hole where there has been data, then take
another snapshot and try to send an incremental stream, btrfs send would
give you EIO. That is because is_extent_unchanged had no support for holes
being punched. With this patch, instead of returning EIO we just return
0 (== the extent is not unchanged) and we're good.
Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
Cc: Alexander Block <ablock84@gmail.com>
Signed-off-by: NJosef Bacik <jbacik@fusionio.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This patch adds the flag, BTRFS_SEND_FLAG_NO_FILE_DATA to the btrfs send
ioctl code. When this flag is set, the btrfs send code will never write file
data into the stream (thus also avoiding expensive reads of that data in the
first place). BTRFS_SEND_C_UPDATE_EXTENT commands will be sent (instead of
BTRFS_SEND_C_WRITE) with an offset, length pair indicating the extent in
question.

This patch does not affect the operation of BTRFS_SEND_C_CLONE commands -
they will continue to be sent when a search finds an appropriate extent to
clone from.
Signed-off-by: NMark Fasheh <mfasheh@suse.de>
Signed-off-by: NJosef Bacik <jbacik@fusionio.com>

All we do is set it to NULL and test it :)
Signed-off-by: NEric Sandeen <sandeen@redhat.com>
Signed-off-by: NJosef Bacik <jbacik@fusionio.com>

We should free name_cache_entry before returning from the
error handling code.
Signed-off-by: NTsutomu Itoh <t-itoh@jp.fujitsu.com>

Originally root_times_lock was introduced as part of send/receive
code however newly developed patch to label the subvol reused
the same lock, so renaming it for a meaningful name.
Signed-off-by: NAnand Jain <anand.jain@oracle.com>
Signed-off-by: NChris Mason <chris.mason@fusionio.com>

This patch also requires a change in the user-space part of "receive".
We need to use "lchown" instead of "chown". We will do this in the
following patch.
Signed-off-by: NAlex Lyakas <alex.btrfs@zadarastorage.com>

 	if (S_ISREG(sctx->cur_inode_mode)) {

When sending a device file, the stream was missing the mode. Also the
rdev was encoded wrongly.
Signed-off-by: NArne Jansen <sensille@gmx.net>

This adds support for the new extended inode refs to btrfs send.
Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>

Developing service cmds needs it.
Signed-off-by: NAnand Jain <anand.jain@oracle.com>

In logical resolve, we parse extent_from_logical()'s 'ret' as a kind of flag.

It is possible to lose our errors because
(-EXXXX & BTRFS_EXTENT_FLAG_TREE_BLOCK) is true.

I'm not sure if it is on purpose, it just looks too hacky if it is.
I'd rather use a real flag and a 'ret' to catch errors.
Acked-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: NLiu Bo <liub.liubo@gmail.com>

Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: NChris Mason <chris.mason@fusionio.com>

The btrfs send code was assuming the offset of the file item into the
extent translated to bytes on disk.  If we're compressed, this isn't
true, and so it was off into extents owned by other files.

It was also improperly handling inline extents.  This solves a crash
where we may have gone past the end of the file extent item by not
testing early enough for an inline extent.  It also solves problems
where we have a whole between the end of the inline item and the start
of the full extent.
Signed-off-by: NChris Mason <chris.mason@fusionio.com>

We can't do the deleted/reused logic for top/root inodes as it would
create a stream that tries to delete and recreate the root dir.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

We have to ignore inode/space cache objects in send/receive.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

We need to pass the root that we determined earlier to iterate_inode_ref.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

Used the wrong compare operator here.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

The previous check was working fine, but this check should be
easier to read. Also, we could theoritically have some exotic
bugs with the previous checks.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

Both were leaked in case of error.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

A leftover from older code and unused now.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

Doing some code cleanups as suggested by Arne.
Changes do not change any logic.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

As the subject already said, add/fix comments.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

Updating send_progress in process_recorded_refs was not correct.
It got updated too early in the cur_inode_new_gen case.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Reported-by: NArne Jansen <sensille@gmx.net>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

We can't easily use the index of the radix tree for inums as the
radix tree uses 32bit indexes on 32bit kernels. For 32bit kernels,
we now use the lower 32bit of the inum as index and an additional
list to store multiple entries per radix tree entry.
Reported-by: NArne Jansen <sensille@gmx.net>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

When everything is done, name_cache_free is called which however
forgot to call kfree on the cache entries.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

If we break, we may miss the clone from send_root which we prefer
over all other clones.

Commit is a result of Arne's review.
Reported-by: NArne Jansen <sensille@gmx.net>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

Don't have a seperate return path for the mentioned case. Now
we do the same "take lowest inode/offset" logic for all found clones.

Commit is a result of Arne's review.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

Make sure to never get in trouble due to the backref_ctx
which was on the stack before.

Commit is a result of Arne's review.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

The new name should be easier to understand/read.

Commit is a result of Arne's review.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

use_list is a leftover and unused.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

We only added the parent for the new position of a moved dir.
We also need to add the old parent of the moved dir.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

fs_path_remove is not used at the moment due to a previous patch.
Remove it for now (with #if 0) to avoid compile warnings.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

We missed that check which resultet in all refs with the same name
being reported as first_ref.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

When the current inodes inum is smaller then the inum of the
parent directory strange things were happending due to wrong
path resolution and other bugs. Fix this with a new approach
for the problem.
Reported-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

We need rdev in the next commit.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>

On powerpc, we don't get the implicit vmalloc.h include, and as a result
the build fails noisily:

  fs/btrfs/send.c: In function 'fs_path_free':
  fs/btrfs/send.c:185:4: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
  fs/btrfs/send.c: In function 'fs_path_ensure_buf':
  fs/btrfs/send.c:215:4: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration]
  fs/btrfs/send.c:215:12: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c:225:12: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c:233:13: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c: In function 'iterate_dir_item':
  fs/btrfs/send.c:900:10: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c:909:11: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c: In function 'btrfs_ioctl_send':
  fs/btrfs/send.c:4463:17: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c:4469:17: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c:4475:2: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
  fs/btrfs/send.c:4475:20: warning: assignment makes pointer from integer without a cast [enabled by default]
  fs/btrfs/send.c:4483:21: warning: assignment makes pointer from integer without a cast [enabled by default]
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NChris Mason <chris.mason@fusionio.com>

This patch introduces the BTRFS_IOC_SEND ioctl that is
required for send. It allows btrfs-progs to implement
full and incremental sends. Patches for btrfs-progs will
follow.
Signed-off-by: NAlexander Block <ablock84@googlemail.com>
Reviewed-by: NDavid Sterba <dave@jikos.cz>
Reviewed-by: NArne Jansen <sensille@gmx.net>
Reviewed-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
Reviewed-by: NAlex Lyakas <alex.bolshoy.btrfs@gmail.com>