Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1738517pxa; Thu, 20 Aug 2020 20:31:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoa3gi2OnvdU7o8DLa1SEhJDNwRIrUwxxjdxJEUPNLHXCCflawgBV84/1a+KtQ5VN2jEoB X-Received: by 2002:a17:906:a3d0:: with SMTP id ca16mr1014508ejb.36.1597980675008; Thu, 20 Aug 2020 20:31:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597980674; cv=none; d=google.com; s=arc-20160816; b=I/VsV0C1yJq/Vw/tmX7luivqQedvnovxl3PGugsNRSlAJ7E5/EfPjhrUTRD7BkTOC1 fvPZmE+zcZYm1u3YDmxQaXNM8Dn78EIg6+tQo+CNsXHTm2hHPZASLhqp41cGlYoR+7ZB H79d8QuwLaROQWm/JJra5o1vA+o18xpOi3onDtYUW5+2N373mxGQexKFgklZ4MQmueq5 sM243mQJWp5uS3O0+bAXhHYgaYMxr+tq+6mD8oCu6AvDkXcaVGVysY6H+B3v766Qxrr0 QTmAn/BjCEkYxaYErMqiCeX4g2SvQiE+3XSGl1WNTZWW1c54SM31bb8gAGdTQYxypuk4 cAug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=mqMipfFxAhFP9IXccuiRfTgI9EhL9JTdB+RkoJtnolI=; b=vfxKq9C7MyWZKWyuT5adyYBfxnk83UQ/xwobmQCPPuRTxBTDthIfMq6zprhfjtEcvB qIqN5tvjoQ+VJudQkmUCOV+Cwntrg1acIJUyaQJa511V+Jv3DDnas0Hh8p/aRYlXjwG+ TWe+gFzL+B3Xrq7EhKZmzo/AsjjzD8bJRVCx02hgmnpDD5GKmfEIYVZSteoetWCIXxA/ RIzcPRXNJnCLa3Dx9sm8cqEVyk8O+5vQEzKr8rVgLYcncMWD6yoSPLaXzT/r9EMkuG31 +v0m8vjMk9bgN5D0s2eqOs+9F0AKAhxtCFZ0KapEhtp5NK9CMoqIg4Fb3l9PYCGb9pDh CseQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mpdesouza.com header.s=default header.b=pRlD8xLC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n17si390590edt.242.2020.08.20.20.30.50; Thu, 20 Aug 2020 20:31:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@mpdesouza.com header.s=default header.b=pRlD8xLC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727090AbgHUD2c (ORCPT + 99 others); Thu, 20 Aug 2020 23:28:32 -0400 Received: from gateway36.websitewelcome.com ([192.185.198.13]:28800 "EHLO gateway36.websitewelcome.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726844AbgHUD2c (ORCPT ); Thu, 20 Aug 2020 23:28:32 -0400 X-Greylist: delayed 1500 seconds by postgrey-1.27 at vger.kernel.org; Thu, 20 Aug 2020 23:28:32 EDT Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway36.websitewelcome.com (Postfix) with ESMTP id E9799401CA004 for ; Thu, 20 Aug 2020 21:07:45 -0500 (CDT) Received: from br540.hostgator.com.br ([108.179.252.180]) by cmsmtp with SMTP id 8x1FkZr92CjCV8x1FkOOzI; Thu, 20 Aug 2020 21:43:05 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mpdesouza.com; s=default; h=Content-Transfer-Encoding:MIME-Version: Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=mqMipfFxAhFP9IXccuiRfTgI9EhL9JTdB+RkoJtnolI=; b=pRlD8xLCWlfRtNoWKbKm+7SWzN iJdeAd1OKKgY4WWHVAqK4rmS9SUIDjWkp6Uaes41S3M20eXWgL+Pqr1jYtaYzJPo+LUNOLYNSBMVK bBnKQqdrjT1Bld3fFZgKz4yiiJpwAkpYwKfy8f430GKSJNeeqop5USxIjIv8UAQXjeBCajHwtby2b STPO7ClblZIYHrhv5U06XYRVu1xcVe2wTEqlpm+EkuzPd0AztPXa4FdpJBoLRJ77jbmZe+jQrIKs5 jt/RcsFHAbAmd8Oao/RFRtZ5IAgW6PXH/+YqrTpcCeKueukU0REzAeOhFbhwgm6EhuEpIg132AWHG SpGwJnxw==; Received: from [191.248.104.145] (port=44546 helo=hephaestus.suse.de) by br540.hostgator.com.br with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1k8x1E-000UJv-Uo; Thu, 20 Aug 2020 23:43:05 -0300 From: Marcos Paulo de Souza To: linux-kernel@vger.kernel.org Cc: dsterba@suse.com, wqu@suse.com, linux-btrfs@vger.kernel.org, Marcos Paulo de Souza , stable@vger.kernel.org Subject: [PATCH] btrfs: block-group: Fix free-space bitmap threshould Date: Thu, 20 Aug 2020 23:42:31 -0300 Message-Id: <20200821024231.16256-1-marcos@mpdesouza.com> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - br540.hostgator.com.br X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mpdesouza.com X-BWhitelist: no X-Source-IP: 191.248.104.145 X-Source-L: No X-Exim-ID: 1k8x1E-000UJv-Uo X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (hephaestus.suse.de) [191.248.104.145]:44546 X-Source-Auth: marcos@mpdesouza.com X-Email-Count: 6 X-Source-Cap: bXBkZXNvNTM7bXBkZXNvNTM7YnI1NDAuaG9zdGdhdG9yLmNvbS5icg== X-Local-Domain: yes Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marcos Paulo de Souza [BUG] After commit 9afc66498a0b ("btrfs: block-group: refactor how we read one block group item"), cache->length is being assigned after calling btrfs_create_block_group_cache. This causes a problem since set_free_space_tree_thresholds is calculate the free-space threshould to decide is the free-space tree should convert from extents to bitmaps. The current code calls set_free_space_tree_thresholds with cache->length being 0, which then makes cache->bitmap_high_thresh being zero. This implies the system will always use bitmap instead of extents, which is not desired if the block group is not fragmented. This behavior can be seen by a test that expects to repair systems with FREE_SPACE_EXTENT and FREE_SPACE_BITMAP, but the current code only created FREE_SPACE_BITMAP. [FIX] Call set_free_space_tree_thresholds after setting cache->length. Link: https://github.com/kdave/btrfs-progs/issues/251 Fixes: 9afc66498a0b ("btrfs: block-group: refactor how we read one block group item") CC: stable@vger.kernel.org # 5.8+ Signed-off-by: Marcos Paulo de Souza --- fs/btrfs/block-group.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 44fdfa2eeb2e..01e8ba1da1d3 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -1798,7 +1798,6 @@ static struct btrfs_block_group *btrfs_create_block_group_cache( cache->fs_info = fs_info; cache->full_stripe_len = btrfs_full_stripe_len(fs_info, start); - set_free_space_tree_thresholds(cache); cache->discard_index = BTRFS_DISCARD_INDEX_UNUSED; @@ -1908,6 +1907,8 @@ static int read_one_block_group(struct btrfs_fs_info *info, read_block_group_item(cache, path, key); + set_free_space_tree_thresholds(cache); + if (need_clear) { /* * When we mount with old space cache, we need to @@ -2128,6 +2129,7 @@ int btrfs_make_block_group(struct btrfs_trans_handle *trans, u64 bytes_used, return -ENOMEM; cache->length = size; + set_free_space_tree_thresholds(cache); cache->used = bytes_used; cache->flags = type; cache->last_byte_to_unpin = (u64)-1; -- 2.28.0