From patchwork Thu Mar 30 14:39:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13194292 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F37CC761A6 for ; Thu, 30 Mar 2023 14:39:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232488AbjC3OjS (ORCPT ); Thu, 30 Mar 2023 10:39:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232251AbjC3OjR (ORCPT ); Thu, 30 Mar 2023 10:39:17 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DCBCDE for ; Thu, 30 Mar 2023 07:39:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 90D1CCE29B7 for ; Thu, 30 Mar 2023 14:39:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52B87C4339B for ; Thu, 30 Mar 2023 14:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680187152; bh=dyRTCfE4RMHbJfWXQTHRgCfg5o0IuUaRLYq06l5iiOY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kUwGbS3siJJdRpGRDu0puFFIQuc/cZogVtOog9iAc1TWLYR7vdWfV0K/U/q1I7ict 4XhXitiAzm/0xiArUycwHtim9kgZJgmAknTdoRIxhjVwUz82VFLPhAgk5Pr6R6KlB7 gGwnAshMI+eA45cuNHZCMc3L8YJ5eIeL29ipd11eVVo9rElb8LgszHhxdp62CPnAFK l4NA+W8H4wPmRijLJw0AfBAUlI3L2ky+LFjtwv61B0yjdf5jkquwQcj4WHu3PXrFeB 4VGCmAe4YCuXGtoUnDps6HwymC4q3nzCgTsWKaZ+4iiU80Cz3KzVHmrFqkVvgAU7Oq dNhxHx5zELWvg== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 1/2] btrfs: make btrfs_block_rsv_full() check more boolean when starting transaction Date: Thu, 30 Mar 2023 15:39:02 +0100 Message-Id: <01834d0e8f0143d09a29ec0541e9ccff63249e1c.1680185833.git.fdmanana@suse.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org From: Filipe Manana When starting a transaction we are comparing the result of a call to btrfs_block_rsv_full() with 0, but the function returns a boolean. While in practice it is not incorrect, as 0 is equivalent to false, it makes it a bit odd and less readable. So update the check to not compare against 0 and instead use the logical not (!) operator. Signed-off-by: Filipe Manana --- fs/btrfs/transaction.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index c57d4408e7f1..a54a5c5a5db3 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -607,7 +607,7 @@ start_transaction(struct btrfs_root *root, unsigned int num_items, */ num_bytes = btrfs_calc_insert_metadata_size(fs_info, num_items); if (flush == BTRFS_RESERVE_FLUSH_ALL && - btrfs_block_rsv_full(delayed_refs_rsv) == 0) { + !btrfs_block_rsv_full(delayed_refs_rsv)) { delayed_refs_bytes = num_bytes; num_bytes <<= 1; } From patchwork Thu Mar 30 14:39:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13194290 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BCD4C6FD1D for ; Thu, 30 Mar 2023 14:39:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231375AbjC3OjQ (ORCPT ); Thu, 30 Mar 2023 10:39:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232071AbjC3OjP (ORCPT ); Thu, 30 Mar 2023 10:39:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB53BDE for ; Thu, 30 Mar 2023 07:39:14 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 35A976206F for ; Thu, 30 Mar 2023 14:39:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E1C2C433EF for ; Thu, 30 Mar 2023 14:39:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680187153; bh=d0z/EYtopePuyYijzLgLw8g1XqODOlNUFKzL1MwGHAA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UHejVH9OCSNfLmCVCMxyYW7aVePuk8sWm8WYSJpD9XWC+FcDzpy96IOplkXX0e/5p LjDF/6o/aSrekARVaOkUxIwcZttgD62ifCuSrXeyJz+gcLGV8wmyiJG2LKHojRfsd4 +JkI1QypglOEP0ptnZ+/W3tzcCRlSoFO/E1uAI9US9p1JpzDhpR1/5sUpwchptUj6o X79LPUyiukz4u7EORfenKAZrylOkDqBFHNfIuvggkZNXMtvDIikmdgZ1BCPLOiir8E 3puXHDwT0nG2FJg8XxSH9mWDcwvZVvC/BUVHUheSLfXLd4XpiFH+30mUcM15nDQoJ4 YxKgjVtNmUZmA== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 2/2] btrfs: correctly calculate delayed ref bytes when starting transaction Date: Thu, 30 Mar 2023 15:39:03 +0100 Message-Id: <93c382a002210831e1051456cdc5c44dbcef4562.1680185833.git.fdmanana@suse.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org From: Filipe Manana When starting a transaction, we are assuming the number of bytes used for each delayed ref update matches the number of bytes used for each item update, that is the return value of: btrfs_calc_insert_metadata_size(fs_info, num_items) However that is not correct when we are using the free space tree, as we need to multiply that value by 2, since delayed ref updates need to modify the free space tree besides the extent tree. So fix this by using btrfs_calc_delayed_ref_bytes() to get the correct number of bytes used for delayed ref updates. Signed-off-by: Filipe Manana --- fs/btrfs/transaction.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index a54a5c5a5db3..9e7ba07a35e8 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -601,15 +601,16 @@ start_transaction(struct btrfs_root *root, unsigned int num_items, /* * We want to reserve all the bytes we may need all at once, so * we only do 1 enospc flushing cycle per transaction start. We - * accomplish this by simply assuming we'll do 2 x num_items - * worth of delayed refs updates in this trans handle, and - * refill that amount for whatever is missing in the reserve. + * accomplish this by simply assuming we'll do num_items worth + * of delayed refs updates in this trans handle, and refill that + * amount for whatever is missing in the reserve. */ num_bytes = btrfs_calc_insert_metadata_size(fs_info, num_items); if (flush == BTRFS_RESERVE_FLUSH_ALL && !btrfs_block_rsv_full(delayed_refs_rsv)) { - delayed_refs_bytes = num_bytes; - num_bytes <<= 1; + delayed_refs_bytes = btrfs_calc_delayed_ref_bytes(fs_info, + num_items); + num_bytes += delayed_refs_bytes; } /*