On Sun, Feb 16, 2014 at 2:23 PM, Marc MERLIN <m...@merlins.org> wrote:
> 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).
Hi Marc,
Some replies below inlined.
>
> 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?
I think it's a different problem.
The issues I have been fixing are about child directories with lower
inode numbers then their parents and renaming/moving them.
>
> 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?
Those ox-y-z names are for orphan inodes, and generated by btrfs send yes.
Since you don't seem to know the sequence of steps (filesystem ops)
that lead to that issue, perhaps you can run 'tree -a --inodes'
against the root of the subvolume and lets us know what the full
output is. That might help in case it's one more case similar to those
I have been fixing recently.
thanks
>
> 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
--
Filipe David Manana,
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
--
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
