| Message ID | 1385743045-2969-1-git-send-email-wangshilong1991@gmail.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
Em 29-11-2013 16:37, Wang Shilong escreveu: > From: Wang Shilong <wangsl.fnst@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) ? best, Miguel Negrão
cc:linux-btrfs ---------- Forwarded message ---------- From: Shilong Wang <wangshilong1991@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-lists@friendlyvirus.org> Hello Miguel, 2013/11/30 Miguel Negrão <miguel.negrao-lists@friendlyvirus.org>: > Em 29-11-2013 16:37, Wang Shilong escreveu: >> From: Wang Shilong <wangsl.fnst@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Miguel, On Sat, Nov 30, 2013 at 1:43 PM, Miguel Negrão <miguel.negrao-lists@friendlyvirus.org> wrote: > Em 29-11-2013 16:37, Wang Shilong escreveu: >> From: Wang Shilong <wangsl.fnst@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/cmds-send.c b/cmds-send.c index 53e9a53..6fdfd7f 100644 --- a/cmds-send.c +++ b/cmds-send.c @@ -282,31 +282,21 @@ out: return ERR_PTR(ret); } -static int do_send(struct btrfs_send *send, u64 root_id, u64 parent_root_id, - int is_first_subvol, int is_last_subvol) +static int do_send(struct btrfs_send *send, u64 parent_root_id, + int is_first_subvol, int is_last_subvol, char *subvol) { int ret; pthread_t t_read; pthread_attr_t t_attr; struct btrfs_ioctl_send_args io_send; - struct subvol_info *si; void *t_err = NULL; int subvol_fd = -1; int pipefd[2] = {-1, -1}; - si = subvol_uuid_search(&send->sus, root_id, NULL, 0, NULL, - subvol_search_by_root_id); - if (!si) { - ret = -ENOENT; - fprintf(stderr, "ERROR: could not find subvol info for %llu", - root_id); - goto out; - } - - subvol_fd = openat(send->mnt_fd, si->path, O_RDONLY | O_NOATIME); + subvol_fd = openat(send->mnt_fd, subvol, O_RDONLY | O_NOATIME); if (subvol_fd < 0) { ret = -errno; - fprintf(stderr, "ERROR: open %s failed. %s\n", si->path, + fprintf(stderr, "ERROR: open %s failed. %s\n", subvol, strerror(-ret)); goto out; } @@ -385,10 +375,6 @@ out: close(pipefd[0]); if (pipefd[1] != -1) close(pipefd[1]); - if (si) { - free(si->path); - free(si); - } return ret; } @@ -664,14 +650,6 @@ int cmd_send(int argc, char **argv) goto out; } - ret = get_root_id(&send, get_subvol_name(send.root_path, subvol), - &root_id); - if (ret < 0) { - fprintf(stderr, "ERROR: could not resolve root_id " - "for %s\n", subvol); - goto out; - } - if (!full_send && !parent_root_id) { ret = find_good_parent(&send, root_id, &parent_root_id); if (ret < 0) { @@ -700,8 +678,8 @@ int cmd_send(int argc, char **argv) is_first_subvol = 1; is_last_subvol = 1; } - ret = do_send(&send, root_id, parent_root_id, - is_first_subvol, is_last_subvol); + ret = do_send(&send, parent_root_id, is_first_subvol, + is_last_subvol, subvol); if (ret < 0) goto out;