From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([222.73.24.84]:23775 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751945Ab3LRDyw (ORCPT ); Tue, 17 Dec 2013 22:54:52 -0500 Message-ID: <52B11C67.2010900@cn.fujitsu.com> Date: Wed, 18 Dec 2013 11:54:15 +0800 From: Wang Shilong MIME-Version: 1.0 To: linux-btrfs@vger.kernel.org, mwd@md5i.com Subject: Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume References: <1387271629-11315-1-git-send-email-wangsl.fnst@cn.fujitsu.com> <20131217150919.GP6498@twin.jikos.cz> <52B10EBE.4030508@cn.fujitsu.com> <8761qmsup8.fsf@maru2.md5i.com> In-Reply-To: <8761qmsup8.fsf@maru2.md5i.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: Hello Michael, On 12/18/2013 11:29 AM, Michael Welsh Duggan wrote: > Miao Xie writes: > >> On Tue, 17 Dec 2013 10:40:41 -0500, Michael Welsh Duggan wrote: >>> David Sterba 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