Btrfs-progs: receive: fix the case that we can not find the subvolume

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>

1 files changed, 10 insertions, 5 deletions

diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index c11b53ae..8fea115a 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -660,11 +660,16 @@ Receive subvolumes from stdin.
 Receives one or more subvolumes that were previously
 sent with btrfs send. The received subvolumes are stored
 into \fI<mount>\fP.
-btrfs receive will fail in case a receiving subvolume
-already exists. It will also fail in case a previously
-received subvolume was changed after it was received.
-After receiving a subvolume, it is immediately set to
-read only.
+btrfs receive will fail with the following case:
+
+1.a receiving subvolume already exists.
+
+2.a previously received subvolume was changed after it was received.
+
+3.default subvolume is changed or you don't mount btrfs filesystem with
+fs tree.
+
+After receiving a subvolume, it is immediately set to read only.
 .RS
 
 \fIOptions\fR