From patchwork Thu Jan 5 08:25:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: robbieko X-Patchwork-Id: 9498625 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 133F660235 for ; Thu, 5 Jan 2017 08:27:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 04E8828173 for ; Thu, 5 Jan 2017 08:27:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EDF6328179; Thu, 5 Jan 2017 08:27:15 +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 6C0B22818E for ; Thu, 5 Jan 2017 08:27:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033266AbdAEI1H (ORCPT ); Thu, 5 Jan 2017 03:27:07 -0500 Received: from synology.com ([59.124.61.242]:40368 "EHLO synology.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033112AbdAEI0e (ORCPT ); Thu, 5 Jan 2017 03:26:34 -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 8ED2B6BAB39; Thu, 5 Jan 2017 16:25:27 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synology.com; s=123; t=1483604727; bh=l0eCV7S6vCGSXDvJ5lach4vw08MuHWHXdByZVGJa+tk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EJvQmAP4Pb9h0FWiwKtPg3VL1q/cRtuQ2ZkGxygzBOszxZi5K+eA8n5ubSzBXFnFf 7ns6W2AZJpoBbqAKe/FqJeBYtejRi0RyyND1ImU615nkzxUb+XoW9rUrffbfL7Rw77 T+YprYSNR2v5l23gGymllwuxO6LN3qgqwcjX9Bnc= From: robbieko To: linux-btrfs@vger.kernel.org Cc: Robbie Ko Subject: [PATCH v3 6/6] Btrfs: incremental send, fix invalid utime operations Date: Thu, 5 Jan 2017 16:25:00 +0800 Message-Id: <1483604700-21017-7-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: 8ED2B6BAB39.AFC35 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 utime operation that will make the receiving end fail when attempting to execute it, because the path has been deleted. Exampla scenario: Parent snapshot: |---- dir258/ (ino 258, gen 7, dir) |--- dir257/ (ino 257, gen 7, dir) |---- dir259/ (ino 259, gen 7, dir) Send snapshot: |---- file258 (ino 258, gen 10, file) |---- new_dir259/ (ino 259, gen 10, dir) |--- dir257/ (ino 257, gen 7, dir) mkdir o259-10-0 rename dir258 -> o258-7-0 utimes mkfile o258-10-0 rename o258-10-0 -> file258 utimes truncate file258 size=0 chown file258 - uid=0, gid=0 chmod file258 - mode=0644 utimes file258 rmdir dir259 utimes rename o259-10-0 -> new_dir259 utimes chown new_dir259 - uid=0, gid=0 chmod new_dir259 - mode=0755 rename o258-7-0/dir257 -> new_dir259/dir257 rmdir o258-7-0 utimes new_dir259/dir257 utimes o258-7-0 ERROR: utimes o258-7-0 failed: No such file or directory While computing the send stream the following steps happen: 1) While processing inode 257 we create o259-10-0, and delaying dir257 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 inode 258 we orphanize dir258, and rename it to o258-7-0, because under dir258 there is a dir257 waiting to be moved; 3) Finally, when 259 is finished processing we rename o258-7-0/dir257 to new_dir259/dir257, and then remove directory o258-7-0. After updating the time in the two parents if it's exist, we only check whether the inode number exists in the send snapshot, which result in utimes error, because old parent has been deleted; Fix this by adding generation check in existence demtermination for the parent directory. Signed-off-by: Robbie Ko --- V3: improve the change log fs/btrfs/send.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index 81a2bee..b4a4724 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -3338,14 +3338,17 @@ finish: /* * The parent inode might have been deleted in the send snapshot */ + u64 gen; ret = get_inode_info(sctx->send_root, cur->dir, NULL, - NULL, NULL, NULL, NULL, NULL); - if (ret == -ENOENT) { + &gen, NULL, NULL, NULL, NULL); + + if (ret < 0 && ret != -ENOENT) + goto out; + + if (ret == -ENOENT || gen != cur->dir_gen) { ret = 0; continue; } - if (ret < 0) - goto out; ret = send_utimes(sctx, cur->dir, cur->dir_gen); if (ret < 0)