From patchwork Thu Jan 5 08:24:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: robbieko X-Patchwork-Id: 9498665 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 ED0A960235 for ; Thu, 5 Jan 2017 08:45:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E2F1927E71 for ; Thu, 5 Jan 2017 08:45:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D4B1627F99; Thu, 5 Jan 2017 08:45:03 +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 7017227D13 for ; Thu, 5 Jan 2017 08:45:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033294AbdAEI1a (ORCPT ); Thu, 5 Jan 2017 03:27:30 -0500 Received: from synology.com ([59.124.61.242]:45010 "EHLO synology.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033253AbdAEI1A (ORCPT ); Thu, 5 Jan 2017 03:27:00 -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 756CC6BA910; Thu, 5 Jan 2017 16:25:20 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synology.com; s=123; t=1483604720; bh=E1euzd/OaPbsPEoAoEMjnkpjONwuVu9PgMh7h3zaOkU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=cDE58dqhs9+vjLnJyP7nKfdhhtQvDfHuci7Zr/d6F+egiObL5UvY2nldYIMcD+e1+ sRcTCPN2deRJ0p3b/ZZlJOlP1DJ9rb0NMbimfCU6A6D6+rNurUpj2Opvc9ufjVG/0Z U+WysHyacibxMAWCYkWqbEpjDiIqGVXjDkhWYmow= From: robbieko To: linux-btrfs@vger.kernel.org Cc: Robbie Ko 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 Message-Id: <1483604700-21017-2-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: 756CC6BA910.AC73D 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 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 --- 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)