* [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.