From patchwork Thu Jan 5 08:24:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: robbieko X-Patchwork-Id: 9498631 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 843F5606E0 for ; Thu, 5 Jan 2017 08:27:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7640428173 for ; Thu, 5 Jan 2017 08:27:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6B2492819A; Thu, 5 Jan 2017 08:27:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D4EE928179 for ; Thu, 5 Jan 2017 08:27:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161067AbdAEI1f (ORCPT ); Thu, 5 Jan 2017 03:27:35 -0500 Received: from synology.com ([59.124.61.242]:40369 "EHLO synology.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033225AbdAEI0f (ORCPT ); Thu, 5 Jan 2017 03:26:35 -0500 Received: from localhost.localdomain (unknown [10.12.12.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: robbieko@synology.com) by synology.com (Postfix) with ESMTPSA id E3CCE6BAAA6; Thu, 5 Jan 2017 16:25:25 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synology.com; s=123; t=1483604726; bh=OemMedA2VqNUrDQD2K41hVXKyBfMXQC5pouQfBEFMi4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=n2CTPRRnvd1bWjChlD4Xrl9vmFud/Vtpsg+dIXkASEhlyPezpElx5r0yKFhMSAPOl Ibp5jjKvecgjKMXSJQbnV0QEKKgYMIQZeBsT3oo0qRAj5XNbJggU8E0JAQspGs2WQv /6s6mwq9TPHeXDxBYeFt4SISptUsVvXUWbHYemPw= From: robbieko To: linux-btrfs@vger.kernel.org Cc: Robbie Ko Subject: [PATCH v3 5/6] Btrfs: incremental send, fix invalid rename operations Date: Thu, 5 Jan 2017 16:24:59 +0800 Message-Id: <1483604700-21017-6-git-send-email-robbieko@synology.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1483604700-21017-1-git-send-email-robbieko@synology.com> References: <1483604700-21017-1-git-send-email-robbieko@synology.com> X-MailScanner-ID: E3CCE6BAAA6.AFD9E X-MailScanner: Found to be clean X-MailScanner-MCPCheck: MCP-Clean, MCP-Checker (score=0, required 80) X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-0.889, required 4.5, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, T_DKIM_INVALID 0.01, URIBL_BLOCKED 0.00) X-MailScanner-From: robbieko@synology.com Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Robbie Ko 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 source has been deleted. Example scenario: Parent snapshot: |---- d1/ (ino 257, gen 44) |---- d4/ (ino 258, gen 44) |---- d3/ (ino 259, gen 44) Send snapshot: |---- d1/ (ino 258, gen 47) |---- d4/ (ino 260, gen 47) |---- d3/ (ino 259, gen 47) |---- d1/ (ino 257, gen 47) rmdir d1 mkdir o257-47-0 mkdir o259-47-0 chown o257-47-0 - uid=0, gid=0 chmod o257-47-0 - mode=0755 rmdir d4 mkdir o258-47-0 rename d1 -> o257-44-0 ERROR: rename d1 -> o257-44-0 failed: No such file or directory While computing the send stream the following steps happen: 1) While processing inode 257 we remove the d1 (ino 257, gen 44), create o257-47-0 and o259-47-0, and delay o257-47-0 rename operation because its new parent in the send snapshot, inode 259, was not yet processed and therefore not yet renamed; 2) Later when processing on inode 258, after we create o258-47-0 before rename it to d1, we need to check whether it will overwrite others. It shows it will overwrite to d1 (inode 257, gen 44) so needs to rename d1 (inode 257, gen 44) to unique name. But it was previously removed, which leads to rename failed. The reason why we thought d1 (inode 257, gen 44) would be overwirtten is inode 257 with diffent generation 47 is waiting for move, then we are mislead they are the same since we miss the generation check for them. Fix this by adding generation check for the inode if it is waiting for move. Signed-off-by: Robbie Ko --- V3: improve the change log fs/btrfs/send.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index 139f492..81a2bee 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -1857,6 +1857,7 @@ static int will_overwrite_ref(struct send_ctx *sctx, u64 dir, u64 dir_gen, u64 gen; u64 other_inode = 0; u8 other_type = 0; + struct waiting_dir_move *dm = NULL; if (!sctx->parent_root) goto out; @@ -1898,11 +1899,15 @@ static int will_overwrite_ref(struct send_ctx *sctx, u64 dir, u64 dir_gen, * overwrite anything at this point in time. */ if (other_inode > sctx->send_progress || - is_waiting_for_move(sctx, other_inode)) { + ((dm = get_waiting_dir_move(sctx, other_inode)) != NULL)) { ret = get_inode_info(sctx->parent_root, other_inode, NULL, who_gen, NULL, NULL, NULL, NULL); if (ret < 0) goto out; + if (dm && dm->gen != *who_gen) { + ret = 0; + goto out; + } ret = 1; *who_ino = other_inode;