All of lore.kernel.org
 help / color / mirror / Atom feed
From: robbieko <robbieko@synology.com>
To: linux-btrfs@vger.kernel.org
Cc: Robbie Ko <robbieko@synology.com>
Subject: [PATCH v3 1/6] Btrfs: incremental send, fix failure to rename with the name collision
Date: Thu,  5 Jan 2017 16:24:55 +0800	[thread overview]
Message-ID: <1483604700-21017-2-git-send-email-robbieko@synology.com> (raw)
In-Reply-To: <1483604700-21017-1-git-send-email-robbieko@synology.com>

From: Robbie Ko <robbieko@synology.com>

Under certain situations, an incremental send operation can
a rename operation that will make the receiving end fail when
attempting to execute it, because the target is exist.

Example scenario:
Parent snapshot:
|.                (ino 256, gen 5)
|---- a1/         (ino 257, gen 5)
|---- a2/         (ino 258, gen 5)

Send snapshot:
|.                (ino 256, gen 7)
|---- a2          (ino 257, gen 7)

rmdir a1
mkfile o257-7-0
rename o257-7-0 -> a2
ERROR: rename o257-7-0 -> a2 failed: Is a directory

While computing the send stream the following steps happen:

1) delete a1;

2) mkfile o257-7-0;

3) rename o257-7-0->a2;

In step 3 we will check whether it will lead to overwrite.

The generation number of inode 257's parent (ino 256) in send snapshot
is 7, which is inconsistent with the one in parent snapshot (gen 5).
For the general parent directory except inode 256, if its generation
is not identical between parent and send snapshot, it will be removed
then created. Thus it's not possible to happen overwrite under the new
directory. However for the special inode 256, the above logic does not
work since it is a subvolume. So overwrite check is required for the
inode 256.
Fix by skipping generation inconsistency check for inode 256.

Signed-off-by: Robbie Ko <robbieko@synology.com>
---
V3: improve the change log
 fs/btrfs/send.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index a87675f..2060e75 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -1681,6 +1681,9 @@ static int is_inode_existent(struct send_ctx *sctx, u64 ino, u64 gen)
 {
 	int ret;
 
+	if (ino == BTRFS_FIRST_FREE_OBJECTID)
+		return 1;
+
 	ret = get_cur_inode_state(sctx, ino, gen);
 	if (ret < 0)
 		goto out;
@@ -1866,7 +1869,7 @@ static int will_overwrite_ref(struct send_ctx *sctx, u64 dir, u64 dir_gen,
 	 * not deleted and then re-created, if it was then we have no overwrite
 	 * and we can just unlink this entry.
 	 */
-	if (sctx->parent_root) {
+	if (sctx->parent_root && dir != BTRFS_FIRST_FREE_OBJECTID) {
 		ret = get_inode_info(sctx->parent_root, dir, NULL, &gen, NULL,
 				     NULL, NULL, NULL);
 		if (ret < 0 && ret != -ENOENT)
-- 
1.9.1


  reply	other threads:[~2017-01-05  8:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05  8:24 [PATCH v3 0/6] Btrfs: incremental send, fix serval case failure robbieko
2017-01-05  8:24 ` robbieko [this message]
2017-01-19 12:05   ` [PATCH v3 1/6] Btrfs: incremental send, fix failure to rename with the name collision Filipe Manana
2017-01-05  8:24 ` [PATCH v3 2/6] Btrfs: incremental send, fix invalid path for truncate operations robbieko
2017-01-19 12:05   ` Filipe Manana
2017-01-05  8:24 ` [PATCH v3 3/6] Btrfs: incremental send, fix not necessary waiting for rmdir operation robbieko
2017-01-05  8:24 ` [PATCH v3 4/6] Btrfs: incremental send, fix invalid path for rmdir operations robbieko
2017-01-19 12:06   ` Filipe Manana
2017-01-05  8:24 ` [PATCH v3 5/6] Btrfs: incremental send, fix invalid rename operations robbieko
2017-01-05  8:25 ` [PATCH v3 6/6] Btrfs: incremental send, fix invalid utime operations robbieko
2017-01-20 18:52 ` [PATCH v3 0/6] Btrfs: incremental send, fix serval case failure David Sterba

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=1483604700-21017-2-git-send-email-robbieko@synology.com \
    --to=robbieko@synology.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.