All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
@ 2013-12-17  9:13 Wang Shilong
  2013-12-17 15:09 ` David Sterba
  0 siblings, 1 reply; 12+ messages in thread
From: Wang Shilong @ 2013-12-17  9:13 UTC (permalink / raw)
  To: linux-btrfs; +Cc: miaox, mwd, Wang Shilong

If we change our default subvolume, btrfs receive will fail to find
subvolume. To fix this problem, i have two 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.

We'd better use the second approach because it won't bother kernel change.

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>
---
 cmds-receive.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
 utils.c        | 28 ++++++++++++++++++++++++++++
 utils.h        |  1 +
 3 files changed, 76 insertions(+), 4 deletions(-)

diff --git a/cmds-receive.c b/cmds-receive.c
index ed44107..c2cf8a3 100644
--- a/cmds-receive.c
+++ b/cmds-receive.c
@@ -40,6 +40,7 @@
 #include <sys/types.h>
 #include <sys/xattr.h>
 #include <uuid/uuid.h>
+#include <sys/mount.h>
 
 #include "ctree.h"
 #include "ioctl.h"
@@ -199,6 +200,10 @@ static int process_snapshot(const char *path, const u8 *uuid, u64 ctransid,
 	char uuid_str[BTRFS_UUID_UNPARSED_SIZE];
 	struct btrfs_ioctl_vol_args_v2 args_v2;
 	struct subvol_info *parent_subvol = NULL;
+	char *dev = NULL;
+	char tmp_name[15] = "btrfs-XXXXXX";
+	char tmp_dir[30] = "/tmp";
+	char *full_path = NULL;
 
 	ret = finish_subvol(r);
 	if (ret < 0)
@@ -253,13 +258,47 @@ static int process_snapshot(const char *path, const u8 *uuid, u64 ctransid,
 		}
 	}*/
 
-	args_v2.fd = openat(r->mnt_fd, parent_subvol->path,
-			O_RDONLY | O_NOATIME);
+	ret = mnt_to_dev(r->root_path, &dev);
+	if (ret)
+		goto out;
+	if (!mktemp(tmp_name)) {
+		fprintf(stderr, "ERROR: fail to generate a tmp file\n");
+		goto out;
+	}
+	strncat(tmp_dir, "/", 1);
+	strncat(tmp_dir, tmp_name, strlen(tmp_name));
+
+	ret = mkdir(tmp_dir, 0777);
+	if (ret) {
+		fprintf(stderr, "ERROR: fail to make dir: %s\n", tmp_dir);
+		goto out;
+	}
+	/* if we change default subvolume, using btrfs interval
+	 * subvolume path to lookup may return us ENOENT.To handle
+	 * such case, we mount this btrfs filesystem other place
+	 * where we use fs tree as our default subvolume.
+	 */
+	ret = mount(dev, tmp_dir, "btrfs", 0, "-o subvolid=5");
+	if (ret) {
+		fprintf(stderr, "ERROR: fail to mount dev: %s", dev);
+		goto out;
+	}
+
+	full_path = calloc(1, strlen(parent_subvol->path) + strlen(tmp_dir));
+	if (!full_path) {
+		ret = -ENOMEM;
+		goto out_umount;
+	}
+	strncat(full_path, tmp_dir, strlen(tmp_dir));
+	strncat(full_path, "/", 1);
+	strncat(full_path, parent_subvol->path, strlen(parent_subvol->path));
+
+	args_v2.fd = open(full_path, O_RDONLY | O_NOATIME);
 	if (args_v2.fd < 0) {
 		ret = -errno;
 		fprintf(stderr, "ERROR: open %s failed. %s\n",
 				parent_subvol->path, strerror(-ret));
-		goto out;
+		goto out_umount;
 	}
 
 	ret = ioctl(r->dest_dir_fd, BTRFS_IOC_SNAP_CREATE_V2, &args_v2);
@@ -269,10 +308,14 @@ static int process_snapshot(const char *path, const u8 *uuid, u64 ctransid,
 		fprintf(stderr, "ERROR: creating snapshot %s -> %s "
 				"failed. %s\n", parent_subvol->path,
 				path, strerror(-ret));
-		goto out;
 	}
 
+out_umount:
+	umount(tmp_dir);
+	rmdir(tmp_dir);
 out:
+	free(full_path);
+	free(dev);
 	if (parent_subvol) {
 		free(parent_subvol->path);
 		free(parent_subvol);
diff --git a/utils.c b/utils.c
index a92696e..da5291b 100644
--- a/utils.c
+++ b/utils.c
@@ -2194,6 +2194,34 @@ out:
 	return ret;
 }
 
+/*
+ * Given mount point, this function will return
+ * its corresponding device
+ */
+int mnt_to_dev(const char *mnt_dir, char **dev)
+{
+	struct mntent *mnt;
+	FILE *f;
+	int ret = -1;
+
+	f = setmntent("/proc/self/mounts", "r");
+	if (f == NULL)
+		return ret;
+	while ((mnt = getmntent(f)) != NULL) {
+		if (strcmp(mnt->mnt_type, "btrfs"))
+			continue;
+		if (strcmp(mnt->mnt_dir, mnt_dir))
+			continue;
+		*dev = strdup(mnt->mnt_fsname);
+		if (*dev)
+			ret = 0;
+		break;
+	}
+	endmntent(f);
+
+	return ret;
+}
+
 /* This finds the mount point for a given fsid,
  *  subvols of the same fs/fsid can be mounted
  *  so here this picks and lowest subvol id
diff --git a/utils.h b/utils.h
index 00f1c18..9b2f79c 100644
--- a/utils.h
+++ b/utils.h
@@ -98,5 +98,6 @@ int btrfs_scan_lblkid(int update_kernel);
 int get_btrfs_mount(const char *dev, char *mp, size_t mp_size);
 int get_fslist(struct btrfs_ioctl_fslist **out_fslist, u64 *out_count);
 int fsid_to_mntpt(__u8 *fsid, char *mntpt, int *mnt_cnt);
+int mnt_to_dev(const char *mnt, char **dev);
 
 #endif
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-17  9:13 [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume Wang Shilong
@ 2013-12-17 15:09 ` David Sterba
  2013-12-17 15:27   ` Wang Shilong
  2013-12-17 15:40   ` Michael Welsh Duggan
  0 siblings, 2 replies; 12+ messages in thread
From: David Sterba @ 2013-12-17 15:09 UTC (permalink / raw)
  To: Wang Shilong; +Cc: linux-btrfs, miaox, mwd

On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
> If we change our default subvolume, btrfs receive will fail to find
> subvolume. To fix this problem, i have two 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
   again

> We'd better use the second approach because it won't bother kernel change.

I don't think that the silent mount is the right way to fix it, that way
the btrfs tool tooks responsibility not to break anything.  Like the
unhandled umount failure below. I think admins and power users do not
like to see some random tool mess with the system like this.

> @@ -199,6 +200,10 @@ static int process_snapshot(const char *path, const u8 *uuid, u64 ctransid,
>  	char uuid_str[BTRFS_UUID_UNPARSED_SIZE];
>  	struct btrfs_ioctl_vol_args_v2 args_v2;
>  	struct subvol_info *parent_subvol = NULL;
> +	char *dev = NULL;
> +	char tmp_name[15] = "btrfs-XXXXXX";
> +	char tmp_dir[30] = "/tmp";

Mounting valuable data under /tmp is dangerous, what if some /tmp
cleaner starts to remove old files. I've seen that happen in practice.

> @@ -269,10 +308,14 @@ static int process_snapshot(const char *path, const u8 *uuid, u64 ctransid,
>  		fprintf(stderr, "ERROR: creating snapshot %s -> %s "
>  				"failed. %s\n", parent_subvol->path,
>  				path, strerror(-ret));
> -		goto out;
>  	}
>  
> +out_umount:
> +	umount(tmp_dir);

umount fails for whatever reason,

> +	rmdir(tmp_dir);

at least this does not delete the files recursively.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-17 15:09 ` David Sterba
@ 2013-12-17 15:27   ` Wang Shilong
  2013-12-17 15:40   ` Michael Welsh Duggan
  1 sibling, 0 replies; 12+ messages in thread
From: Wang Shilong @ 2013-12-17 15:27 UTC (permalink / raw)
  To: dsterba; +Cc: Wang Shilong, linux-btrfs, miaox, mwd


Hi dave,

> On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
>> If we change our default subvolume, btrfs receive will fail to find
>> subvolume. To fix this problem, i have two 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
>   again

If we really don't want to bother kernel change, i think we can add a option for btrfs receive(for example -f)
to force tool to resolve such ENOENT and at the same time, we output something like:

fprintf(stderr, "Default subvolume is changed,……….")

if -f is not assigned, we will fail here.

> 
>> We'd better use the second approach because it won't bother kernel change.
> 
> I don't think that the silent mount is the right way to fix it, that way
> the btrfs tool tooks responsibility not to break anything.  Like the
> unhandled umount failure below. I think admins and power users do not
> like to see some random tool mess with the system like this.

> 
>> @@ -199,6 +200,10 @@ static int process_snapshot(const char *path, const u8 *uuid, u64 ctransid,
>> 	char uuid_str[BTRFS_UUID_UNPARSED_SIZE];
>> 	struct btrfs_ioctl_vol_args_v2 args_v2;
>> 	struct subvol_info *parent_subvol = NULL;
>> +	char *dev = NULL;
>> +	char tmp_name[15] = "btrfs-XXXXXX";
>> +	char tmp_dir[30] = "/tmp";
> 
> Mounting valuable data under /tmp is dangerous, what if some /tmp
> cleaner starts to remove old files. I've seen that happen in practice.

Agree with  this.

> 
>> @@ -269,10 +308,14 @@ static int process_snapshot(const char *path, const u8 *uuid, u64 ctransid,
>> 		fprintf(stderr, "ERROR: creating snapshot %s -> %s "
>> 				"failed. %s\n", parent_subvol->path,
>> 				path, strerror(-ret));
>> -		goto out;
>> 	}
>> 
>> +out_umount:
>> +	umount(tmp_dir);
> 
> umount fails for whatever reason,

will fix it.

> 
>> +	rmdir(tmp_dir);
> 
> at least this does not delete the files recursively.

Why we need delete the files recursively here,
I only create dir ,something like /tmp/btrfs-XXXXX, and i only want to delete the temp dir
btrfs-XXXX here…

Thanks,
Wang

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-17 15:09 ` David Sterba
  2013-12-17 15:27   ` Wang Shilong
@ 2013-12-17 15:40   ` Michael Welsh Duggan
  2013-12-18  2:55     ` Miao Xie
  2013-12-19 16:48     ` David Sterba
  1 sibling, 2 replies; 12+ messages in thread
From: Michael Welsh Duggan @ 2013-12-17 15:40 UTC (permalink / raw)
  To: dsterba; +Cc: Wang Shilong, linux-btrfs, miaox

David Sterba <dsterba@suse.cz> writes:

> On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
>> If we change our default subvolume, btrfs receive will fail to find
>> subvolume. To fix this problem, i have two 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
>    again

Ugh.  I hope that would be considered a short-term hack waiting for a
better solution, perhaps requiring a kernel upgrade.  From a user's
perspective there is no reason this should be necessary, and requiring
this would be extraordinarily surprising.  "Why is btrfs unable to find
my snapshot?  It's right there!"  Moreover, this used to work just fine
in previous versions of btrfs-progs.

>> We'd better use the second approach because it won't bother kernel change.
>
> I don't think that the silent mount is the right way to fix it, that way
> the btrfs tool tooks responsibility not to break anything.  Like the
> unhandled umount failure below. I think admins and power users do not
> like to see some random tool mess with the system like this.
>
>> @@ -199,6 +200,10 @@ static int process_snapshot(const char *path,
>> const u8 *uuid, u64 ctransid,
>>  	char uuid_str[BTRFS_UUID_UNPARSED_SIZE];
>>  	struct btrfs_ioctl_vol_args_v2 args_v2;
>>  	struct subvol_info *parent_subvol = NULL;
>> +	char *dev = NULL;
>> +	char tmp_name[15] = "btrfs-XXXXXX";
>> +	char tmp_dir[30] = "/tmp";
>
> Mounting valuable data under /tmp is dangerous, what if some /tmp
> cleaner starts to remove old files. I've seen that happen in practice.

Agreed.  If you _were_ to continue to implement it like this, you should
include code to respect the TMPDIR envvar at the very least.

-- 
Michael Welsh Duggan
(mwd@cert.org)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-17 15:40   ` Michael Welsh Duggan
@ 2013-12-18  2:55     ` Miao Xie
  2013-12-18  3:29       ` Michael Welsh Duggan
  2013-12-19 16:48     ` David Sterba
  1 sibling, 1 reply; 12+ messages in thread
From: Miao Xie @ 2013-12-18  2:55 UTC (permalink / raw)
  To: Michael Welsh Duggan, dsterba; +Cc: Wang Shilong, linux-btrfs

On Tue, 17 Dec 2013 10:40:41 -0500, Michael Welsh Duggan wrote:
> David Sterba <dsterba@suse.cz> writes:
> 
>> On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
>>> If we change our default subvolume, btrfs receive will fail to find
>>> subvolume. To fix this problem, i have two 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
>>    again
> 
> Ugh.  I hope that would be considered a short-term hack waiting for a
> better solution, perhaps requiring a kernel upgrade.  From a user's
> perspective there is no reason this should be necessary, and requiring
> this would be extraordinarily surprising.  "Why is btrfs unable to find
> my snapshot?  It's right there!"  Moreover, this used to work just fine
> in previous versions of btrfs-progs.

Though the snapshot is still in the fs, it is inaccessible because you mount
some subvolume as the root, and you can not find the path to the snapshot.

For example:
There are two subvolumes in the fs, and they are in the root directory of the
fs, just like
	real root directory
	 |->subv0
	 |->subv1

Then if you mount the subv1 as the root directory, the real root directory of
the fs and subv0 will be shielded,
	+-------------------+
	|real root directory|
	| |->subv0          |
	+-------------------+
	  |->subv1
you can only access the files, directories, subvolumes... in the subv1. So the tool
will report "can not find ...."

BTW, it is impossible that the previous version of btrfs-progs can work well in
this case.

>>> We'd better use the second approach because it won't bother kernel change.
>>
>> I don't think that the silent mount is the right way to fix it, that way
>> the btrfs tool tooks responsibility not to break anything.  Like the
>> unhandled umount failure below. I think admins and power users do not
>> like to see some random tool mess with the system like this.
>>
>>> @@ -199,6 +200,10 @@ static int process_snapshot(const char *path,
>>> const u8 *uuid, u64 ctransid,
>>>  	char uuid_str[BTRFS_UUID_UNPARSED_SIZE];
>>>  	struct btrfs_ioctl_vol_args_v2 args_v2;
>>>  	struct subvol_info *parent_subvol = NULL;
>>> +	char *dev = NULL;
>>> +	char tmp_name[15] = "btrfs-XXXXXX";
>>> +	char tmp_dir[30] = "/tmp";
>>
>> Mounting valuable data under /tmp is dangerous, what if some /tmp
>> cleaner starts to remove old files. I've seen that happen in practice.
> 
> Agreed.  If you _were_ to continue to implement it like this, you should
> include code to respect the TMPDIR envvar at the very least.

Since the TMPDIR is not safe, I think the approach that David said is better.
Let's tell the users why we can not find the subvolume, and ask the users to
make the final decision.

Thanks
Miao

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-18  2:55     ` Miao Xie
@ 2013-12-18  3:29       ` Michael Welsh Duggan
  2013-12-18  3:54         ` Wang Shilong
  0 siblings, 1 reply; 12+ messages in thread
From: Michael Welsh Duggan @ 2013-12-18  3:29 UTC (permalink / raw)
  To: linux-btrfs

Miao Xie <miaox@cn.fujitsu.com> writes:

> On Tue, 17 Dec 2013 10:40:41 -0500, Michael Welsh Duggan wrote:
>> David Sterba <dsterba@suse.cz> writes:
>> 
>>> On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
>>>> If we change our default subvolume, btrfs receive will fail to find
>>>> subvolume. To fix this problem, i have two 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
>>>    again
>> 
>> Ugh.  I hope that would be considered a short-term hack waiting for a
>> better solution, perhaps requiring a kernel upgrade.  From a user's
>> perspective there is no reason this should be necessary, and requiring
>> this would be extraordinarily surprising.  "Why is btrfs unable to find
>> my snapshot?  It's right there!"  Moreover, this used to work just fine
>> in previous versions of btrfs-progs.
>
> Though the snapshot is still in the fs, it is inaccessible because you
> mount
> some subvolume as the root, and you can not find the path to the snapshot.
>
> For example:
> There are two subvolumes in the fs, and they are in the root directory
> of the
> fs, just like
> 	real root directory
> 	 |->subv0
> 	 |->subv1
>
> Then if you mount the subv1 as the root directory, the real root
> directory of
> the fs and subv0 will be shielded,
> 	+-------------------+
> 	|real root directory|
> 	| |->subv0          |
> 	+-------------------+
> 	  |->subv1
> you can only access the files, directories, subvolumes... in the subv1. So the tool
> will report "can not find ...."
>
> BTW, it is impossible that the previous version of btrfs-progs can work well in
> this case.

In that case I either misunderstand completely, or my problem is almost
decidedly different.  To recap, this is the command that failed:

    # ./btrfs send -p /snapshots/bo /snapshots/bp | ./btrfs receive /backup/snapshots/root/
    At subvol /snapshots/bp
    At snapshot bp
    ioctl(BTRFS_IOC_TREE_SEARCH, uuid, key 48f0ebae83fd32f1, UUID_KEY, 90139d8200afeaab) ret=-1, error: No such file or directory
    ioctl(BTRFS_IOC_TREE_SEARCH, uuid, key 48f0ebae83fd32f1, UUID_KEY, 90139d8200afeaab) ret=-1, error: No such file or directory
    ERROR: could not find parent subvolume

Now, I believe you are saying that this means that it can't find the
"bo" snapshot in the backup volume.  But it is mounted in the expected
location:

    # ls -ld /backup/snapshots/root/bo/
    drwxr-xr-x 1 root root 280 Dec 13 17:54 /backup/snapshots/root/bo/

and 

    # ./btrfs sub list -p /backup/ | grep root/bo
    ID 1030 gen 1046 parent 5 top level 5 path snapshots/root/bo

    # btrfs sub show /backup/snapshots/root/bo/
    /backup/snapshots/root/bo
            Name:                   bo
            uuid:                   5e15ef24-f2d0-194f-886d-3f7afc7413a4
            Parent uuid:            9a226af3-8497-744b-90f7-d7e54d58946d
            Creation time:          2013-12-13 17:51:57
            Object ID:              1030
            Generation (Gen):       1046
            Gen at creation:        1042
            Parent:                 5
            Top Level:              5
            Flags:                  readonly
            Snapshot(s):

Maybe I am missing some terminology here?  Is there some output I can
send to make the problem clearer?

-- 
Michael Welsh Duggan
(md5i@md5i.com)


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-18  3:29       ` Michael Welsh Duggan
@ 2013-12-18  3:54         ` Wang Shilong
  2013-12-18  4:06           ` Michael Welsh Duggan
  0 siblings, 1 reply; 12+ messages in thread
From: Wang Shilong @ 2013-12-18  3:54 UTC (permalink / raw)
  To: linux-btrfs, mwd

Hello Michael,

On 12/18/2013 11:29 AM, Michael Welsh Duggan wrote:
> Miao Xie <miaox@cn.fujitsu.com> writes:
>
>> On Tue, 17 Dec 2013 10:40:41 -0500, Michael Welsh Duggan wrote:
>>> David Sterba <dsterba@suse.cz> writes:
>>>
>>>> On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
>>>>> If we change our default subvolume, btrfs receive will fail to find
>>>>> subvolume. To fix this problem, i have two 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
>>>>     again
>>> Ugh.  I hope that would be considered a short-term hack waiting for a
>>> better solution, perhaps requiring a kernel upgrade.  From a user's
>>> perspective there is no reason this should be necessary, and requiring
>>> this would be extraordinarily surprising.  "Why is btrfs unable to find
>>> my snapshot?  It's right there!"  Moreover, this used to work just fine
>>> in previous versions of btrfs-progs.
>> Though the snapshot is still in the fs, it is inaccessible because you
>> mount
>> some subvolume as the root, and you can not find the path to the snapshot.
>>
>> For example:
>> There are two subvolumes in the fs, and they are in the root directory
>> of the
>> fs, just like
>> 	real root directory
>> 	 |->subv0
>> 	 |->subv1
>>
>> Then if you mount the subv1 as the root directory, the real root
>> directory of
>> the fs and subv0 will be shielded,
>> 	+-------------------+
>> 	|real root directory|
>> 	| |->subv0          |
>> 	+-------------------+
>> 	  |->subv1
>> you can only access the files, directories, subvolumes... in the subv1. So the tool
>> will report "can not find ...."
>>
>> BTW, it is impossible that the previous version of btrfs-progs can work well in
>> this case.
> In that case I either misunderstand completely, or my problem is almost
> decidedly different.  To recap, this is the command that failed:
>
>      # ./btrfs send -p /snapshots/bo /snapshots/bp | ./btrfs receive /backup/snapshots/root/
>      At subvol /snapshots/bp
>      At snapshot bp
>      ioctl(BTRFS_IOC_TREE_SEARCH, uuid, key 48f0ebae83fd32f1, UUID_KEY, 90139d8200afeaab) ret=-1, error: No such file or directory
>      ioctl(BTRFS_IOC_TREE_SEARCH, uuid, key 48f0ebae83fd32f1, UUID_KEY, 90139d8200afeaab) ret=-1, error: No such file or directory
>      ERROR: could not find parent subvolume
>
It seems that you use older kernel version but use the latest 
btrfs-progs, new btrfs-progs use uuid tree to search but
this tree did not exist yet.

Can you try to upgrade your kernel?

Thanks,
Wang

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-18  3:54         ` Wang Shilong
@ 2013-12-18  4:06           ` Michael Welsh Duggan
  2013-12-18  5:03             ` Wang Shilong
  0 siblings, 1 reply; 12+ messages in thread
From: Michael Welsh Duggan @ 2013-12-18  4:06 UTC (permalink / raw)
  To: Wang Shilong; +Cc: linux-btrfs, mwd

Wang Shilong <wangsl.fnst@cn.fujitsu.com> writes:

> It seems that you use older kernel version but use the latest
> btrfs-progs, new btrfs-progs use uuid tree to search but
> this tree did not exist yet.
>
> Can you try to upgrade your kernel?

What version is necessary?  (I am currently on 3.11.10.)

-- 
Michael Welsh Duggan
(md5i@md5i.com)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-18  4:06           ` Michael Welsh Duggan
@ 2013-12-18  5:03             ` Wang Shilong
  2013-12-18 20:57               ` Michael Welsh Duggan
  0 siblings, 1 reply; 12+ messages in thread
From: Wang Shilong @ 2013-12-18  5:03 UTC (permalink / raw)
  To: Michael Welsh Duggan; +Cc: linux-btrfs

On 12/18/2013 12:06 PM, Michael Welsh Duggan wrote:
> Wang Shilong <wangsl.fnst@cn.fujitsu.com> writes:
>
>> It seems that you use older kernel version but use the latest
>> btrfs-progs, new btrfs-progs use uuid tree to search but
>> this tree did not exist yet.
>>
>> Can you try to upgrade your kernel?
> What version is necessary?  (I am currently on 3.11.10.)
3.12 is ok, btw, can you run for 3.11.10

#dmesg

Let's see if it output somthing like:

btrfs: can not found root: 9

Thanks,
Wang
>


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-18  5:03             ` Wang Shilong
@ 2013-12-18 20:57               ` Michael Welsh Duggan
  2013-12-20  2:33                 ` Michael Welsh Duggan
  0 siblings, 1 reply; 12+ messages in thread
From: Michael Welsh Duggan @ 2013-12-18 20:57 UTC (permalink / raw)
  To: linux-btrfs

Wang Shilong <wangsl.fnst@cn.fujitsu.com> writes:

> On 12/18/2013 12:06 PM, Michael Welsh Duggan wrote:
>> Wang Shilong <wangsl.fnst@cn.fujitsu.com> writes:
>>
>>> It seems that you use older kernel version but use the latest
>>> btrfs-progs, new btrfs-progs use uuid tree to search but
>>> this tree did not exist yet.
>>>
>>> Can you try to upgrade your kernel?
>> What version is necessary?  (I am currently on 3.11.10.)
> 3.12 is ok, btw, can you run for 3.11.10
>
> #dmesg
>
> Let's see if it output somthing like:
>
> btrfs: can not found root: 9

Indeed.

    $ dmesg | grep "root 9"
    [305770.945287] could not find root 9
    [305770.945300] could not find root 9
    [305770.945369] could not find root 9
    [305770.945398] could not find root 9
    [305915.405421] could not find root 9
    [305915.405483] could not find root 9
    [305962.927150] could not find root 9
    [305962.927222] could not find root 9
    [399096.924559] could not find root 9
    [399096.924617] could not find root 9
    [399195.585768] could not find root 9
    [399195.585823] could not find root 9

Looks like I'll be rebooting to a new kernel when I get home tonight.

-- 
Michael Welsh Duggan
(md5i@md5i.com)


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-17 15:40   ` Michael Welsh Duggan
  2013-12-18  2:55     ` Miao Xie
@ 2013-12-19 16:48     ` David Sterba
  1 sibling, 0 replies; 12+ messages in thread
From: David Sterba @ 2013-12-19 16:48 UTC (permalink / raw)
  To: Michael Welsh Duggan; +Cc: dsterba, Wang Shilong, linux-btrfs, miaox

On Tue, Dec 17, 2013 at 10:40:41AM -0500, Michael Welsh Duggan wrote:
> David Sterba <dsterba@suse.cz> writes:
> 
> > On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
> >> If we change our default subvolume, btrfs receive will fail to find
> >> subvolume. To fix this problem, i have two 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
> >    again
> 
> Ugh.  I hope that would be considered a short-term hack waiting for a
> better solution, perhaps requiring a kernel upgrade.  From a user's
> perspective there is no reason this should be necessary, and requiring
> this would be extraordinarily surprising.  "Why is btrfs unable to find
> my snapshot?  It's right there!"  Moreover, this used to work just fine
> in previous versions of btrfs-progs.

It is a short-term fix, one that we can apply immediatelly without
breaking things. A long-term fix is #1, but this would need more work
and testing.

david

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
  2013-12-18 20:57               ` Michael Welsh Duggan
@ 2013-12-20  2:33                 ` Michael Welsh Duggan
  0 siblings, 0 replies; 12+ messages in thread
From: Michael Welsh Duggan @ 2013-12-20  2:33 UTC (permalink / raw)
  To: linux-btrfs

Michael Welsh Duggan <mwd@md5i.com> writes:

> Wang Shilong <wangsl.fnst@cn.fujitsu.com> writes:
>
>> On 12/18/2013 12:06 PM, Michael Welsh Duggan wrote:
>>> Wang Shilong <wangsl.fnst@cn.fujitsu.com> writes:
>>>
>>>> It seems that you use older kernel version but use the latest
>>>> btrfs-progs, new btrfs-progs use uuid tree to search but
>>>> this tree did not exist yet.
>>>>
>>>> Can you try to upgrade your kernel?
>>> What version is necessary?  (I am currently on 3.11.10.)
>> 3.12 is ok, btw, can you run for 3.11.10
>>
> Looks like I'll be rebooting to a new kernel when I get home tonight.

Running with a 3.12 kernel does solve this problem for me.  Thank you
for your help.

-- 
Michael Welsh Duggan
(md5i@md5i.com)


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-12-20  2:33 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-17  9:13 [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume Wang Shilong
2013-12-17 15:09 ` David Sterba
2013-12-17 15:27   ` Wang Shilong
2013-12-17 15:40   ` Michael Welsh Duggan
2013-12-18  2:55     ` Miao Xie
2013-12-18  3:29       ` Michael Welsh Duggan
2013-12-18  3:54         ` Wang Shilong
2013-12-18  4:06           ` Michael Welsh Duggan
2013-12-18  5:03             ` Wang Shilong
2013-12-18 20:57               ` Michael Welsh Duggan
2013-12-20  2:33                 ` Michael Welsh Duggan
2013-12-19 16:48     ` David Sterba

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.