From: Filipe David Borba Manana <fdmanana@gmail.com>
To: linux-btrfs@vger.kernel.org
Cc: Filipe David Borba Manana <fdmanana@gmail.com>
Subject: [PATCH v3] Btrfs: fix incremental send's decision to delay a dir move/rename
Date: Sun, 16 Mar 2014 20:37:26 +0000 [thread overview]
Message-ID: <1395002246-3840-1-git-send-email-fdmanana@gmail.com> (raw)
In-Reply-To: <1394983430-20440-1-git-send-email-fdmanana@gmail.com>
It's possible to change the parent/child relationship between directories
in such a way that if a child directory has a higher inode number than
its parent, it doesn't necessarily means the child rename/move operation
can be performed immediately. The parent migth have its own rename/move
operation delayed, therefore in this case the child needs to have its
rename/move operation delayed too, and be performed after its new parent's
rename/move.
Steps to reproduce the issue:
$ umount /mnt
$ mkfs.btrfs -f /dev/sdd
$ mount /dev/sdd /mnt
$ mkdir /mnt/A
$ mkdir /mnt/B
$ mkdir /mnt/C
$ mv /mnt/C /mnt/A
$ mv /mnt/B /mnt/A/C
$ mkdir /mnt/A/C/D
$ btrfs subvolume snapshot -r /mnt /mnt/snap1
$ btrfs send /mnt/snap1 -f /tmp/base.send
$ mv /mnt/A/C/D /mnt/A/D2
$ mv /mnt/A/C/B /mnt/A/D2/B2
$ mv /mnt/A/C /mnt/A/D2/B2/C2
$ btrfs subvolume snapshot -r /mnt /mnt/snap2
$ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/incremental.send
The incremental send caused the kernel code to enter an infinite loop when
building the path string for directory C after its references are processed.
The necessary conditions here are that C has an inode number higher than both
A and B, and B as an higher inode number higher than A, and D has the highest
inode number, that is:
inode_number(A) < inode_number(B) < inode_number(C) < inode_number(D)
The same issue could happen if after the first snapshot there's any number
of intermediary parent directories between A2 and B2, and between B2 and C2.
A test case for xfstests follows, covering this simple case and more advanced
ones, with files and hard links created inside the directories.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
---
V2: Right version of the patch. Previously sent came from the wrong vm.
V3: The condition needed to check already existed, so just moved it to the
top, instead of adding it again.
fs/btrfs/send.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 6463691..d869079 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -3184,12 +3184,12 @@ static int wait_for_parent_move(struct send_ctx *sctx,
struct fs_path *path_after = NULL;
int len1, len2;
- if (parent_ref->dir <= sctx->cur_ino)
- return 0;
-
if (is_waiting_for_move(sctx, ino))
return 1;
+ if (parent_ref->dir <= sctx->cur_ino)
+ return 0;
+
ret = get_inode_info(sctx->parent_root, ino, NULL, &old_gen,
NULL, NULL, NULL, NULL);
if (ret == -ENOENT)
--
1.7.10.4
next prev parent reply other threads:[~2014-03-16 20:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-16 15:23 [PATCH] Btrfs: fix incremental send's decision to delay a dir move/rename Filipe David Borba Manana
2014-03-16 17:09 ` [PATCH v2] " Filipe David Borba Manana
2014-03-16 20:37 ` Filipe David Borba Manana [this message]
2014-03-16 22:20 ` How to handle a RAID5 arrawy with a failing drive? Marc MERLIN
2014-03-16 22:55 ` Chris Murphy
2014-03-16 23:12 ` Chris Murphy
2014-03-16 23:17 ` Marc MERLIN
2014-03-16 23:23 ` Chris Murphy
2014-03-17 0:51 ` Marc MERLIN
2014-03-17 1:06 ` Chris Murphy
2014-03-17 1:17 ` Marc MERLIN
2014-03-17 2:56 ` Chris Murphy
2014-03-17 3:44 ` Marc MERLIN
2014-03-17 5:12 ` Chris Murphy
2014-03-17 16:13 ` Marc MERLIN
2014-03-17 17:38 ` Chris Murphy
2014-03-16 23:40 ` ronnie sahlberg
2014-03-16 23:20 ` Chris Murphy
2014-03-18 9:02 ` Duncan
2014-03-19 6:09 ` How to handle a RAID5 arrawy with a failing drive? -> raid5 mostly works, just no rebuilds Marc MERLIN
2014-03-19 6:32 ` Chris Murphy
2014-03-19 15:40 ` Marc MERLIN
2014-03-19 16:53 ` Chris Murphy
2014-03-19 22:40 ` Marc MERLIN
[not found] ` <CAGwxe4jL+L571MtEmeHnTnHQSD7h+2ApfWqycgV-ymXhfMR-JA@mail.gmail.com>
2014-03-20 0:46 ` Marc MERLIN
2014-03-20 7:37 ` Tobias Holst
2014-03-23 19:22 ` Marc MERLIN
2014-03-20 7:37 ` Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1395002246-3840-1-git-send-email-fdmanana@gmail.com \
--to=fdmanana@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox