cc:linux-btrfs ---------- Forwarded message ---------- From: Shilong Wang <wangshilong1...@gmail.com> Date: 2013/12/1 Subject: Re: [PATCH v2] Btrfs-progs: avoid using btrfs internal subvolume path to send To: Miguel Negrão <miguel.negrao-li...@friendlyvirus.org>
Hello Miguel, 2013/11/30 Miguel Negrão <miguel.negrao-li...@friendlyvirus.org>: > 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. This patch can also fix your case(that you change your default subvolume and mounting with default subvolume) > 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) ? Nope, now, btrfs send is implemented in kernel space, while receive is in userspace totally.But i think canceling/resuming operation for 'btrfs send' is meaningful. Thanks, Wang > > 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
