All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Naohiro Aota <Naohiro.Aota@wdc.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 2/3] btrfs: zoned: fix write time activation failure for metadata block group
Date: Tue, 8 Jul 2025 14:11:20 +0900	[thread overview]
Message-ID: <67d78b3c-e170-4481-ac3f-78ac5a180c6e@kernel.org> (raw)
In-Reply-To: <DB6EQDA4RP4A.2KNYOLWFW6HYR@wdc.com>

On 7/8/25 2:04 PM, Naohiro Aota wrote:
> On Mon Jul 7, 2025 at 12:33 PM JST, Damien Le Moal wrote:
>> On 7/7/25 11:44 AM, Naohiro Aota wrote:
>>> Since commit 13bb483d32ab ("btrfs: zoned: activate metadata block group on
>>> write time"), we activate a metadata block group on the write time. If the
>>
>> on the write time -> at write time
>>
>>> zone capacity is small enough, we can allocate the entire region before the
>>> first write. Then, we hit the btrfs_zoned_bg_is_full() in
>>> btrfs_zone_activate() and the activation fails.
>>>
>>> For a data block group, we already check the fullness condition in the
>>> caller side. And, the fullness check is not necessary for metadata's
>>> write-time activation. Replace it with a proper WARN.
>>
>> I am very confused by this explanation. If the BG is fully allocated before we
>> issue the first write, we still need to activate that BG, no ? So why the
>> WARN() ? That seems wrong to me. But I may not be understanding your
>> explanation, which means you need to clarify it :)
> 
> We activate a data block group before the allocation to simplify the
> write stage. So, activating a full block group should arise WARN.
> 
> OTOH, metadata block group is activated on the write stage. So, it is OK
> to have a full block group to be activated. Instead, it is WARN when we
> try to activate a partially written (meta_write_pointer != bg->start)
> block group.

OK. Please update the commit message with this to clarify.
Also, a comment in the coe would be nice to remind this to whoever read that
code :)

-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2025-07-08  5:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-07  2:44 [PATCH 0/3] btrfs: zoned: limitt active zones to max_open_zones Naohiro Aota
2025-07-07  2:44 ` [PATCH 1/3] btrfs: zoned: do not select metadata BG as finish target Naohiro Aota
2025-07-07  3:29   ` Damien Le Moal
2025-07-07  7:34   ` Johannes Thumshirn
2025-07-07  2:44 ` [PATCH 2/3] btrfs: zoned: fix write time activation failure for metadata block group Naohiro Aota
2025-07-07  3:33   ` Damien Le Moal
2025-07-08  5:04     ` Naohiro Aota
2025-07-08  5:11       ` Damien Le Moal [this message]
2025-07-07  2:44 ` [PATCH 3/3] btrfs: zoned: limit active zones to max_open_zones Naohiro Aota
2025-07-07  3:40   ` Damien Le Moal
2025-07-08  5:16     ` Naohiro Aota

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=67d78b3c-e170-4481-ac3f-78ac5a180c6e@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=Naohiro.Aota@wdc.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 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.