Hi Miguel, On Sat, Nov 30, 2013 at 1:43 PM, Miguel Negrão <miguel.negrao-li...@friendlyvirus.org> wrote: > Em 29-11-2013 16:37, Wang Shilong escreveu: >> From: Wang Shilong <wangsl.f...@cn.fujitsu.com> >> >> Steps to reproduce: >> # mkfs.btrfs -f /dev/sda >> # mount /dev/sda /mnt >> # btrfs subvolume create /mnt/foo >> # umount /mnt >> # mount -o subvol=foo /dev/sda /mnt >> # btrfs sub snapshot -r /mnt /mnt/snap >> # btrfs send /mnt/snap > /dev/null >> >> We will fail to send '/mnt/snap',this is because btrfs send try to >> open '/mnt/snap' by btrfs internal subvolume path 'foo/snap' rather >> than relative path based on mounted point, this will return us 'no >> such file or directory',this is not right, fix it. > > I was going to write to the list to report exactly this issue. In my > case, this happens when the default subvolume has been changed from id 5 > to some other id. I get the error 'no such file or directory'. Currently > my workaround is to mount the root subvolume with -o subvolid=5 and then > do the send. > > Also, I'd like to ask, are there plans to make the send and receive > commands resumeable somehow (or perhaps it is already, but couldn't see > how) ? I have proposed a patch to address the resumability of send-receive some time ago in this thread: http://www.spinics.net/lists/linux-btrfs/msg18180.html
However, this changes the current user-kernel protocol used by "send", and overall a big change, which is not easy to integrate. Alex. > > best, > Miguel Negrão > > > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
