Miao Xie <miaox@xxxxxxxxxxxxxx> writes:
> On Tue, 17 Dec 2013 10:40:41 -0500, Michael Welsh Duggan wrote:
>> David Sterba <dsterba@xxxxxxx> 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@xxxxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
