From: Nikolay Borisov <nborisov@suse.com>
To: Josef Bacik <josef@toxicpanda.com>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 1/2] btrfs: include the free space tree in the global rsv minimum calculation
Date: Thu, 2 Dec 2021 11:07:51 +0200 [thread overview]
Message-ID: <e57e0536-779b-f617-477f-08e3c99c5c81@suse.com> (raw)
In-Reply-To: <13d6e38d365639ac7a6b982f465332a78e0a516e.1638377089.git.josef@toxicpanda.com>
On 1.12.21 г. 18:45, Josef Bacik wrote:
> Filipe reported a problem where generic/619 was failing with an ENOSPC
> abort while running delayed refs, like the following
>
> ------------[ cut here ]------------
> BTRFS: Transaction aborted (error -28)
> WARNING: CPU: 3 PID: 522920 at fs/btrfs/free-space-tree.c:1049 add_to_free_space_tree+0xe5/0x110 [btrfs]
> CPU: 3 PID: 522920 Comm: kworker/u16:19 Tainted: G W 5.16.0-rc2-btrfs-next-106 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]
> RIP: 0010:add_to_free_space_tree+0xe5/0x110 [btrfs]
> RSP: 0000:ffffa65087fb7b20 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000001000 RCX: 0000000000000000
> RDX: 0000000000000001 RSI: ffffffff9131eeaa RDI: 00000000ffffffff
> RBP: ffff8d62e26481b8 R08: ffffffff9ad97ce0 R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000001 R12: 00000000ffffffe4
> R13: ffff8d61c25fe688 R14: ffff8d61ebd88800 R15: ffff8d61ebd88a90
> FS: 0000000000000000(0000) GS:ffff8d64ed400000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fa46a8b1000 CR3: 0000000148d18003 CR4: 0000000000370ee0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> __btrfs_free_extent+0x516/0x950 [btrfs]
> __btrfs_run_delayed_refs+0x2b1/0x1250 [btrfs]
> btrfs_run_delayed_refs+0x86/0x210 [btrfs]
> flush_space+0x403/0x630 [btrfs]
> ? call_rcu_tasks_generic+0x50/0x80
> ? lock_release+0x223/0x4a0
> ? btrfs_get_alloc_profile+0xb5/0x290 [btrfs]
> ? do_raw_spin_unlock+0x4b/0xa0
> btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]
> process_one_work+0x24c/0x5b0
> worker_thread+0x55/0x3c0
> ? process_one_work+0x5b0/0x5b0
> kthread+0x17c/0x1a0
> ? set_kthread_struct+0x40/0x40
> ret_from_fork+0x22/0x30
>
> There's a couple of reasons for this, but in generic/619's case the
> largest reason is because it is a very small file system, ad we do not
> reserve enough space for the global reserve.
>
> With the free space tree we now have the free space tree that we need to
> modify when running delayed refs. This means we need the global reserve
> to take this into account when it calculates the minimum size it needs
> to be. This is especially important for very small file systems.
>
> Fix this by adjusting the minimum global block rsv size math to include
> the size of the free space tree when calculating the size.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
> fs/btrfs/block-rsv.c | 30 +++++++++++++++++-------------
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/fs/btrfs/block-rsv.c b/fs/btrfs/block-rsv.c
> index 21ac60ec19f6..b3086f252ad0 100644
> --- a/fs/btrfs/block-rsv.c
> +++ b/fs/btrfs/block-rsv.c
> @@ -352,25 +352,29 @@ void btrfs_update_global_block_rsv(struct btrfs_fs_info *fs_info)
> {
> struct btrfs_block_rsv *block_rsv = &fs_info->global_block_rsv;
> struct btrfs_space_info *sinfo = block_rsv->space_info;
> - struct btrfs_root *extent_root = btrfs_extent_root(fs_info, 0);
> - struct btrfs_root *csum_root = btrfs_csum_root(fs_info, 0);
> - u64 num_bytes;
> - unsigned min_items;
> + struct btrfs_root *root, *tmp;
> + u64 num_bytes = btrfs_root_used(&fs_info->tree_root->root_item);
> + unsigned int min_items = 1;
>
> /*
> * The global block rsv is based on the size of the extent tree, the
> * checksum tree and the root tree. If the fs is empty we want to set
> * it to a minimal amount for safety.
> + *
> + * We also are going to need to modify the minimum of the tree root and
> + * any global roots we could touch.
> */
> - num_bytes = btrfs_root_used(&extent_root->root_item) +
> - btrfs_root_used(&csum_root->root_item) +
> - btrfs_root_used(&fs_info->tree_root->root_item);
> -
> - /*
> - * We at a minimum are going to modify the csum root, the tree root, and
> - * the extent root.
> - */
> - min_items = 3;
> + read_lock(&fs_info->global_root_lock);
> + rbtree_postorder_for_each_entry_safe(root, tmp, &fs_info->global_root_tree,
> + rb_node) {
> + if (root->root_key.objectid == BTRFS_EXTENT_TREE_OBJECTID ||
> + root->root_key.objectid == BTRFS_CSUM_TREE_OBJECTID ||
> + root->root_key.objectid == BTRFS_FREE_SPACE_TREE_OBJECTID) {
> + num_bytes += btrfs_root_used(&root->root_item);
> + min_items++;
> + }
> + }
nit: I think those changes constitute 2 patches - the first does the
global_root_tree iteration as preparation for global roots. And the
subsequent patch should also include the freespace tree, no ? Otherwise
LGTM.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
> + read_unlock(&fs_info->global_root_lock);
>
> /*
> * But we also want to reserve enough space so we can do the fallback
>
next prev parent reply other threads:[~2021-12-02 9:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1638377089.git.josef@toxicpanda.com>
2021-12-01 16:45 ` [PATCH 1/2] btrfs: include the free space tree in the global rsv minimum calculation Josef Bacik
2021-12-02 9:07 ` Nikolay Borisov [this message]
2021-12-07 19:19 ` David Sterba
2021-12-01 16:45 ` [PATCH 2/2] btrfs: reserve extra space for the free space tree Josef Bacik
2021-12-02 14:14 ` Nikolay Borisov
2021-12-02 15:46 ` Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e57e0536-779b-f617-477f-08e3c99c5c81@suse.com \
--to=nborisov@suse.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).