Commit 3dc09ec8 authored by Josef Bacik's avatar Josef Bacik Committed by David Sterba

Btrfs: kill invalid ASSERT() in process_all_refs()

Suppose you have the following tree in snap1 on a file system mounted with -o
inode_cache so that inode numbers are recycled

└── [    258]  a
    └── [    257]  b

and then you remove b, rename a to c, and then re-create b in c so you have the
following tree

└── [    258]  c
    └── [    257]  b

and then you try to do an incremental send you will hit

ASSERT(pending_move == 0);

in process_all_refs().  This is because we assume that any recycling of inodes
will not have a pending change in our path, which isn't the case.  This is the
case for the DELETE side, since we want to remove the old file using the old
path, but on the create side we could have a pending move and need to do the
normal pending rename dance.  So remove this ASSERT() and put a comment about
why we ignore pending_move.  Thanks,
Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
parent 28a23593
...@@ -4268,10 +4268,12 @@ static int process_all_refs(struct send_ctx *sctx, ...@@ -4268,10 +4268,12 @@ static int process_all_refs(struct send_ctx *sctx,
} }
btrfs_release_path(path); btrfs_release_path(path);
/*
* We don't actually care about pending_move as we are simply
* re-creating this inode and will be rename'ing it into place once we
* rename the parent directory.
*/
ret = process_recorded_refs(sctx, &pending_move); ret = process_recorded_refs(sctx, &pending_move);
/* Only applicable to an incremental send. */
ASSERT(pending_move == 0);
out: out:
btrfs_free_path(path); btrfs_free_path(path);
return ret; return ret;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment