From patchwork Thu Mar 31 02:19:34 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 8706891 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4EFE9C0553 for ; Thu, 31 Mar 2016 02:21:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3F1312037E for ; Thu, 31 Mar 2016 02:21:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 58BAF20376 for ; Thu, 31 Mar 2016 02:21:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752828AbcCaCVt (ORCPT ); Wed, 30 Mar 2016 22:21:49 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:31918 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750928AbcCaCVt (ORCPT ); Wed, 30 Mar 2016 22:21:49 -0400 X-IronPort-AV: E=Sophos;i="5.20,367,1444665600"; d="scan'208";a="418045" Received: from unknown (HELO cn.fujitsu.com) ([10.167.250.3]) by song.cn.fujitsu.com with ESMTP; 31 Mar 2016 10:21:40 +0800 Received: from localhost.localdomain (unknown [10.167.226.34]) by cn.fujitsu.com (Postfix) with ESMTP id 746684056403 for ; Thu, 31 Mar 2016 10:21:34 +0800 (CST) From: Qu Wenruo To: linux-btrfs@vger.kernel.org Subject: [PATCH] btrfs-progs: fsck: Fix a false metadata extent warning Date: Thu, 31 Mar 2016 10:19:34 +0800 Message-Id: <1459390774-12424-1-git-send-email-quwenruo@cn.fujitsu.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-yoursite-MailScanner-ID: 746684056403.AA9C2 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: quwenruo@cn.fujitsu.com X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP At least 2 user from mail list reported btrfsck reported false alert of "bad metadata [XXXX,YYYY) crossing stripe boundary". While the reported number are all inside the same 64K boundary. After some check, all the false alert have the same bytenr feature, which can be divided by stripe size (64K). The result seems to be initial 'max_size' can be 0, causing 'start' + 'max_size' - 1, to cross the stripe boundary. Fix it by always update extent_record->cross_stripe when the extent_record is updated, to avoid temporary false alert to be reported. Signed-off-by: Qu Wenruo --- cmds-check.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index d157075..ef23ddb 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -4579,9 +4579,9 @@ static int add_extent_rec(struct cache_tree *extent_cache, * As now stripe_len is fixed to BTRFS_STRIPE_LEN, just check * it. */ - if (metadata && check_crossing_stripes(rec->start, - rec->max_size)) - rec->crossing_stripes = 1; + if (metadata) + rec->crossing_stripes = check_crossing_stripes( + rec->start, rec->max_size); check_extent_type(rec); maybe_free_extent_rec(extent_cache, rec); return ret; @@ -4641,8 +4641,8 @@ static int add_extent_rec(struct cache_tree *extent_cache, } if (metadata) - if (check_crossing_stripes(rec->start, rec->max_size)) - rec->crossing_stripes = 1; + rec->crossing_stripes = check_crossing_stripes(rec->start, + rec->max_size); check_extent_type(rec); return ret; }