From patchwork Mon May 15 08:27:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 9726361 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 CCF0C60387 for ; Mon, 15 May 2017 08:28:01 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BA2002896E for ; Mon, 15 May 2017 08:28:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AEE572894F; Mon, 15 May 2017 08:28:01 +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.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI 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 28E6228970 for ; Mon, 15 May 2017 08:28:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759970AbdEOI17 (ORCPT ); Mon, 15 May 2017 04:27:59 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:33782 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1759170AbdEOI14 (ORCPT ); Mon, 15 May 2017 04:27:56 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="18851801" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 15 May 2017 16:27:47 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id 5D92E47CE221; Mon, 15 May 2017 16:27:47 +0800 (CST) Received: from localhost.localdomain (10.167.226.34) by G08CNEXCHPEKD02.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 15 May 2017 16:27:50 +0800 From: Qu Wenruo To: , CC: Subject: [PATCH 5/5] btrfs-progs: lowmem check: Fix false alert on missing chunk or dev extent Date: Mon, 15 May 2017 16:27:42 +0800 Message-ID: <20170515082742.21363-5-quwenruo@cn.fujitsu.com> X-Mailer: git-send-email 2.12.2 In-Reply-To: <20170515082742.21363-1-quwenruo@cn.fujitsu.com> References: <20170515082742.21363-1-quwenruo@cn.fujitsu.com> MIME-Version: 1.0 X-Originating-IP: [10.167.226.34] X-yoursite-MailScanner-ID: 5D92E47CE221.AFC92 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: quwenruo@cn.fujitsu.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 When checking chunk or dev extent, lowmem mode uses chunk length as dev extent length, and if they mismatch, report missing chunk or dev extent like: ------ ERROR: chunk[256 4324327424) stripe 0 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 1 did not find the related dev extent ERROR: chunk[256 4324327424) stripe 2 did not find the related dev extent ------ However, only for Single/DUP/RAID1 profiles chunk length is the same as dev extent length. For other profiles, this will cause tons of false alert. Fix it by using correct stripe length when checking chunk and dev extent items. Reported-by: Kai Krakow Signed-off-by: Qu Wenruo --- Test cases for this bug will follow as another patchset, since we need some infrastructure update to support multi-device mkfs/check/mount. --- cmds-check.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index 58b73608..eb3eb9e9 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -10872,7 +10872,12 @@ static int check_dev_extent_item(struct btrfs_fs_info *fs_info, l = path.nodes[0]; chunk = btrfs_item_ptr(l, path.slots[0], struct btrfs_chunk); - if (btrfs_chunk_length(l, chunk) != length) + ret = btrfs_check_chunk_valid(chunk_root, l, chunk, path.slots[0], + chunk_key.offset); + if (ret < 0) + goto out; + + if (btrfs_stripe_length(fs_info, l, chunk) != length) goto out; num_stripes = btrfs_chunk_num_stripes(l, chunk); @@ -11112,6 +11117,7 @@ static int check_chunk_item(struct btrfs_fs_info *fs_info, struct btrfs_dev_extent *ptr; u64 length; u64 chunk_end; + u64 stripe_len; u64 type; int num_stripes; u64 offset; @@ -11161,6 +11167,7 @@ static int check_chunk_item(struct btrfs_fs_info *fs_info, } num_stripes = btrfs_chunk_num_stripes(eb, chunk); + stripe_len = btrfs_stripe_length(fs_info, eb, chunk); for (i = 0; i < num_stripes; i++) { btrfs_release_path(&path); btrfs_init_path(&path); @@ -11180,7 +11187,7 @@ static int check_chunk_item(struct btrfs_fs_info *fs_info, offset = btrfs_dev_extent_chunk_offset(leaf, ptr); if (objectid != chunk_key.objectid || offset != chunk_key.offset || - btrfs_dev_extent_length(leaf, ptr) != length) + btrfs_dev_extent_length(leaf, ptr) != stripe_len) goto not_match_dev; continue; not_match_dev: