Hi Fillipe, I see you have another fix for btrfs send (attached below),
as ell as your other patch on Jan 21st (neither are in my 3.12.7).
>From my error below,
> ERROR: rmdir o1845158-142-0 failed. No such file or directory
can you tell if I'm having a different problem than the two patches
you sent?
More generally, could you hint how I can tell what this
rmdir o1845158-142-0
refers to, considering that it looks like a made up filename by btrfs
send/receive?
I'm happy to go to 3.13.3 and apply both patches if you think it'll
help.
Thanks,
Marc
On Wed, Feb 12, 2014 at 06:22:07AM -0800, Marc MERLIN wrote:
> So, I've veen running this for a few weeks, and soon should have
> something half decent to share for others to use.
>
> Unfortunately, one of my backups is now failing like so:
>
> btrfs send -p "$src_snap" "$src_newsnap" | btrfs receive "$dest_pool/"
> + btrfs send -p /mnt/btrfs_pool1/home_ro.20140209_12:00:01
> home_ro.20140212_05:37:49
> + btrfs receive /mnt/btrfs_pool2//
> At subvol home_ro.20140212_05:37:49
> At snapshot home_ro.20140212_05:37:49
> ERROR: rmdir o1845158-142-0 failed. No such file or directory
>
> This looks like it got in an unfinished state it can't recover from.
>
> This was with kernel 3.12.7.
>
> Can I self fix this somehow, I know I can use rsync to make both sides
> the sames, but incremental send/receive will not work anymore after
> that, correct?
>
> Except, not really. Now I'm confused.
> legolas:/mnt/btrfs_pool1# rsync -avSH --delete --dry-run
> /mnt/btrfs_pool1/home_ro.20140209_12:00:01/.
> /mnt/btrfs_pool2/home_ro.20140209_12\:00\:01/.
> sending incremental file list
> ./
>
> sent 116867233 bytes received 265427 bytes 92194.14 bytes/sec
> total size is 129135042766 speedup is 1102.47 (DRY RUN)
> legolas:/mnt/btrfs_pool1#
>
> (I know I start the entire backup over from scratch, but for obvious
> reasons, restarting an entire backup from scratch each time I get an
> error isn't great since it could take hours or days to backup that much
> data)
>
> Suggestions welcome :)
>
> Thanks,
> Marc
On Sun, Feb 16, 2014 at 01:43:11PM +0000, Filipe David Borba Manana wrote:
> This fixes yet one more case not caught by the commit titled:
>
> Btrfs: fix infinite path build loops in incremental send
>
> In this case, even before the initial full send, we have a directory
> which is a child of a directory with a higher inode number. Then we
> perform the initial send, and after we rename both the child and the
> parent, without moving them around. After doing these 2 renames, an
> incremental send sent a rename instruction for the child directory
> which contained an invalid "from" path (referenced the parent's old
> name, not the new one), which made the btrfs receive command fail.
>
> Steps to reproduce:
>
> $ mkfs.btrfs -f /dev/sdb3
> $ mount /dev/sdb3 /mnt/btrfs
> $ mkdir -p /mnt/btrfs/a/b
> $ mkdir /mnt/btrfs/d
> $ mkdir /mnt/btrfs/a/b/c
> $ mv /mnt/btrfs/d /mnt/btrfs/a/b/c
> $ btrfs subvolume snapshot -r /mnt/btrfs /mnt/btrfs/snap1
> $ btrfs send /mnt/btrfs/snap1 -f /tmp/base.send
> $ mv /mnt/btrfs/a/b/c /mnt/btrfs/a/b/x
> $ mv /mnt/btrfs/a/b/x/d /mnt/btrfs/a/b/x/y
> $ btrfs subvolume snapshot -r /mnt/btrfs /mnt/btrfs/snap2
> $ btrfs send -p /mnt/btrfs/snap1 /mnt/btrfs/snap2 -f /tmp/incremental.send
>
> $ umout /mnt/btrfs
> $ mkfs.btrfs -f /dev/sdb3
> $ mount /dev/sdb3 /mnt/btrfs
> $ btrfs receive /mnt/btrfs -f /tmp/base.send
> $ btrfs receive /mnt/btrfs -f /tmp/incremental.send
>
> The second btrfs receive command failed with:
> "ERROR: rename a/b/c/d -> a/b/x/y failed. No such file or directory"
>
> A test case for xfstests follows.
>
> Signed-off-by: Filipe David Borba Manana <fdman...@gmail.com>
> ---
> fs/btrfs/send.c | 41 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
> index b6d416c..7dbed58 100644
> --- a/fs/btrfs/send.c
> +++ b/fs/btrfs/send.c
> @@ -2847,19 +2847,48 @@ static int apply_dir_move(struct send_ctx *sctx,
> struct pending_dir_move *pm)
> {
> struct fs_path *from_path = NULL;
> struct fs_path *to_path = NULL;
> + struct fs_path *name = NULL;
> u64 orig_progress = sctx->send_progress;
> struct recorded_ref *cur;
> + u64 parent_ino, parent_gen;
> int ret;
>
> + name = fs_path_alloc();
> from_path = fs_path_alloc();
> - if (!from_path)
> - return -ENOMEM;
> + if (!name || !from_path) {
> + ret = -ENOMEM;
> + goto out;
> + }
>
> - sctx->send_progress = pm->ino;
> - ret = get_cur_path(sctx, pm->ino, pm->gen, from_path);
> + ret = del_waiting_dir_move(sctx, pm->ino);
> + ASSERT(ret == 0);
> +
> + ret = get_first_ref(sctx->parent_root, pm->ino,
> + &parent_ino, &parent_gen, name);
> if (ret < 0)
> goto out;
>
> + if (parent_ino == sctx->cur_ino) {
> + /* child only renamed, not moved */
> + ASSERT(parent_gen == sctx->cur_inode_gen);
> + ret = get_cur_path(sctx, sctx->cur_ino, sctx->cur_inode_gen,
> + from_path);
> + if (ret < 0)
> + goto out;
> + ret = fs_path_add_path(from_path, name);
> + if (ret < 0)
> + goto out;
> + } else {
> + /* child moved and maybe renamed too */
> + sctx->send_progress = pm->ino;
> + ret = get_cur_path(sctx, pm->ino, pm->gen, from_path);
> + if (ret < 0)
> + goto out;
> + }
> +
> + fs_path_free(name);
> + name = NULL;
> +
> to_path = fs_path_alloc();
> if (!to_path) {
> ret = -ENOMEM;
> @@ -2867,9 +2896,6 @@ static int apply_dir_move(struct send_ctx *sctx, struct
> pending_dir_move *pm)
> }
>
> sctx->send_progress = sctx->cur_ino + 1;
> - ret = del_waiting_dir_move(sctx, pm->ino);
> - ASSERT(ret == 0);
> -
> ret = get_cur_path(sctx, pm->ino, pm->gen, to_path);
> if (ret < 0)
> goto out;
> @@ -2893,6 +2919,7 @@ static int apply_dir_move(struct send_ctx *sctx, struct
> pending_dir_move *pm)
> }
>
> out:
> + fs_path_free(name);
> fs_path_free(from_path);
> fs_path_free(to_path);
> sctx->send_progress = orig_progress;
> --
> 1.7.9.5
>
> --
> 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
>
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
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
