All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Cc: linux-btrfs@vger.kernel.org, Filipe Manana <fdmanana@suse.com>,
	David Sterba <dsterba@suse.com>,
	Hans Holmberg <Hans.Holmberg@wdc.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	Naohiro Aota <naohiro.aota@wdc.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 3/7] btrfs: zoned: always set data_relocation_bg
Date: Thu, 14 May 2026 07:54:22 -0700	[thread overview]
Message-ID: <20260514145422.GC1197064@zen.localdomain> (raw)
In-Reply-To: <20260513123445.43197-4-johannes.thumshirn@wdc.com>

On Wed, May 13, 2026 at 02:34:41PM +0200, Johannes Thumshirn wrote:
> When searching for a data relocation block-group on mount,
> btrfs_zoned_reserve_data_reloc_bg() is looking for the first empty DATA
> block-group. But it first checks if the block-group is empty and if yes
> continues the search, and then checks if it is the first DATA block-group.
> 
> Reverse the order, first check if it is the first DATA block-group found
> and skip, then check if the block-group is empty. This enusres that there
> is always a DATA block-group set as data_relocation_bg in the filesystem.

You want the second empty block group? or the first? if you want the
first, then checking for "first" ever seems pointless. If you want the
second, then I think you need to layer the "if (first)" inside the
successful non-empty check?

As is, it just unilaterally skips the first bg even if it's not empty
and will grab the first empty one. It makes sense to not use the first
empty for reloc (that's for alloc presumably) but I don't see why just
plain skipping the first one makes sense.

> 
> Singed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> ---
>  fs/btrfs/zoned.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> index 16dd87aa06f2..0b80b498fb85 100644
> --- a/fs/btrfs/zoned.c
> +++ b/fs/btrfs/zoned.c
> @@ -2784,14 +2784,14 @@ void btrfs_zoned_reserve_data_reloc_bg(struct btrfs_fs_info *fs_info)
>  again:
>  	bg_list = &space_info->block_groups[index];
>  	list_for_each_entry(bg, bg_list, list) {
> -		if (bg->alloc_offset != 0)
> -			continue;
> -
>  		if (first) {
>  			first = false;
>  			continue;
>  		}
>  
> +		if (bg->alloc_offset != 0)
> +			continue;
> +
>  		if (space_info == data_sinfo) {
>  			/* Migrate the block group to the data relocation space_info. */
>  			struct btrfs_space_info *reloc_sinfo = data_sinfo->sub_group[0];
> -- 
> 2.54.0
> 

  parent reply	other threads:[~2026-05-14 14:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 12:34 [PATCH 0/7] btrfs: fixes around generic/747 on zoned filesystems Johannes Thumshirn
2026-05-13 12:34 ` [PATCH 1/7] btrfs: zoned: document RECLAIM_ZONES flush state Johannes Thumshirn
2026-05-14 14:44   ` Boris Burkov
2026-05-13 12:34 ` [PATCH 2/7] btrfs: zoned: decode 'RECLAIM_ZONES' state in tracepoints Johannes Thumshirn
2026-05-13 12:34 ` [PATCH 3/7] btrfs: zoned: always set data_relocation_bg Johannes Thumshirn
2026-05-14  5:42   ` Damien Le Moal
2026-05-14 14:54   ` Boris Burkov [this message]
2026-05-13 12:34 ` [PATCH 4/7] btrfs: zoned: don't account data relocation space-info in statfs free space Johannes Thumshirn
2026-05-14  5:42   ` Damien Le Moal
2026-05-15  4:38   ` Christoph Hellwig
2026-05-13 12:34 ` [PATCH 5/7] btrfs: zoned: subtract zone_unusable space in statfs Johannes Thumshirn
2026-05-14  5:43   ` Damien Le Moal
2026-05-15  4:39   ` Christoph Hellwig
2026-05-15  9:26     ` Johannes Thumshirn
2026-05-15 11:34       ` Christoph Hellwig
2026-05-13 12:34 ` [PATCH 6/7] btrfs: zoned: fix deadlock waiting for ticket during data relocation Johannes Thumshirn
2026-05-15 17:26   ` Boris Burkov
2026-05-13 12:34 ` [RFC PATCH 7/7] btrfs: zoned: add RECLAIM_ZONES and RESET_ZONES to first async reclaim loop Johannes Thumshirn
2026-05-15 18:38   ` Boris Burkov
2026-05-14 14:43 ` [PATCH 0/7] btrfs: fixes around generic/747 on zoned filesystems 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=20260514145422.GC1197064@zen.localdomain \
    --to=boris@bur.io \
    --cc=Hans.Holmberg@wdc.com \
    --cc=dlemoal@kernel.org \
    --cc=dsterba@suse.com \
    --cc=fdmanana@suse.com \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.