Btrfs devel - Dec 2013 - [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume

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

--
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

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

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
--
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

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)
--
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

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
--
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

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)

--
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

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
--
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

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)
--
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

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
>
--
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

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)

--
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