Skip to content

Commit 3dc09ec

Browse files
Josef Bacikkdave
authored andcommitted
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: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]>
1 parent 28a2359 commit 3dc09ec

File tree

1 file changed

+5
-3
lines changed

1 file changed

+5
-3
lines changed

fs/btrfs/send.c

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4268,10 +4268,12 @@ static int process_all_refs(struct send_ctx *sctx,
42684268
}
42694269
btrfs_release_path(path);
42704270

4271+
/*
4272+
* We don't actually care about pending_move as we are simply
4273+
* re-creating this inode and will be rename'ing it into place once we
4274+
* rename the parent directory.
4275+
*/
42714276
ret = process_recorded_refs(sctx, &pending_move);
4272-
/* Only applicable to an incremental send. */
4273-
ASSERT(pending_move == 0);
4274-
42754277
out:
42764278
btrfs_free_path(path);
42774279
return ret;

0 commit comments

Comments
 (0)