From: Leo Martins <loemra.dev@gmail.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 1/2] btrfs: remove ffe RAID loop
Date: Mon, 22 Sep 2025 18:13:14 -0700 [thread overview]
Message-ID: <f873e980f092dc282ea934d5a77ca2ad463e377d.1758587352.git.loemra.dev@gmail.com> (raw)
In-Reply-To: <cover.1758587352.git.loemra.dev@gmail.com>
This patch removes the RAID loop from find_free_extent since it
is impossible to allocate from a block group with a different
RAID profile.
Historically, we've been able to fulfill allocation requests
from any block group. For example, a request for RAID0 could be
fulfilled by a RAID1 block group or a request for METADATA could be
fulfilled by a DATA block group.
"btrfs: extent-tree: Make sure we only allocate extents from block
groups with the same type" changed this behavior to skip block groups
with different flags than the request. This makes the duplication
compatibility check redundant since we're going to keep searching
regardless.
Signed-off-by: Leo Martins <loemra.dev@gmail.com>
---
fs/btrfs/extent-tree.c | 40 +++-------------------------------------
1 file changed, 3 insertions(+), 37 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index a4416c451b25..072d9bb84dd8 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4153,8 +4153,7 @@ static int can_allocate_chunk(struct btrfs_fs_info *fs_info,
static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info,
struct btrfs_key *ins,
struct find_free_extent_ctl *ffe_ctl,
- struct btrfs_space_info *space_info,
- bool full_search)
+ struct btrfs_space_info *space_info)
{
struct btrfs_root *root = fs_info->chunk_root;
int ret;
@@ -4171,20 +4170,15 @@ static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info,
if (ffe_ctl->loop >= LOOP_CACHING_WAIT && ffe_ctl->have_caching_bg)
return 1;
- ffe_ctl->index++;
- if (ffe_ctl->index < BTRFS_NR_RAID_TYPES)
- return 1;
-
/* See the comments for btrfs_loop_type for an explanation of the phases. */
if (ffe_ctl->loop < LOOP_NO_EMPTY_SIZE) {
- ffe_ctl->index = 0;
/*
* We want to skip the LOOP_CACHING_WAIT step if we don't have
* any uncached bgs and we've already done a full search
* through.
*/
if (ffe_ctl->loop == LOOP_CACHING_NOWAIT &&
- (!ffe_ctl->orig_have_caching_bg && full_search))
+ (!ffe_ctl->orig_have_caching_bg))
ffe_ctl->loop++;
ffe_ctl->loop++;
@@ -4384,7 +4378,6 @@ static noinline int find_free_extent(struct btrfs_root *root,
int cache_block_group_error = 0;
struct btrfs_block_group *block_group = NULL;
struct btrfs_space_info *space_info;
- bool full_search = false;
WARN_ON(ffe_ctl->num_bytes < fs_info->sectorsize);
@@ -4477,9 +4470,6 @@ static noinline int find_free_extent(struct btrfs_root *root,
search:
trace_btrfs_find_free_extent_search_loop(root, ffe_ctl);
ffe_ctl->have_caching_bg = false;
- if (ffe_ctl->index == btrfs_bg_flags_to_raid_index(ffe_ctl->flags) ||
- ffe_ctl->index == 0)
- full_search = true;
down_read(&space_info->groups_sem);
list_for_each_entry(block_group,
&space_info->block_groups[ffe_ctl->index], list) {
@@ -4498,30 +4488,7 @@ static noinline int find_free_extent(struct btrfs_root *root,
btrfs_grab_block_group(block_group, ffe_ctl->delalloc);
ffe_ctl->search_start = block_group->start;
- /*
- * this can happen if we end up cycling through all the
- * raid types, but we want to make sure we only allocate
- * for the proper type.
- */
if (!block_group_bits(block_group, ffe_ctl->flags)) {
- u64 extra = BTRFS_BLOCK_GROUP_DUP |
- BTRFS_BLOCK_GROUP_RAID1_MASK |
- BTRFS_BLOCK_GROUP_RAID56_MASK |
- BTRFS_BLOCK_GROUP_RAID10;
-
- /*
- * if they asked for extra copies and this block group
- * doesn't provide them, bail. This does allow us to
- * fill raid0 from raid1.
- */
- if ((ffe_ctl->flags & extra) && !(block_group->flags & extra))
- goto loop;
-
- /*
- * This block group has different flags than we want.
- * It's possible that we have MIXED_GROUP flag but no
- * block group is mixed. Just skip such block group.
- */
btrfs_release_block_group(block_group, ffe_ctl->delalloc);
continue;
}
@@ -4620,8 +4587,7 @@ static noinline int find_free_extent(struct btrfs_root *root,
}
up_read(&space_info->groups_sem);
- ret = find_free_extent_update_loop(fs_info, ins, ffe_ctl, space_info,
- full_search);
+ ret = find_free_extent_update_loop(fs_info, ins, ffe_ctl, space_info);
if (ret > 0)
goto search;
--
2.47.3
next prev parent reply other threads:[~2025-09-23 1:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 1:13 [PATCH 0/2] btrfs: find_free_extent cleanups Leo Martins
2025-09-23 1:13 ` Leo Martins [this message]
2025-09-24 18:54 ` [PATCH 1/2] btrfs: remove ffe RAID loop Boris Burkov
2025-09-23 1:13 ` [PATCH 2/2] btrfs: add tracing for find_free_extent skip conditions Leo Martins
2025-09-24 19:14 ` Boris Burkov
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=f873e980f092dc282ea934d5a77ca2ad463e377d.1758587352.git.loemra.dev@gmail.com \
--to=loemra.dev@gmail.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).