Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Cc: linux-btrfs@vger.kernel.org, Naohiro Aota <naohiro.aota@wdc.com>,
	Qu Wenruo <wqu@suse.com>, Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH 1/4] btrfs: zoned: flush active metadata block group at btree_writepages() start
Date: Thu, 23 Jul 2026 08:40:22 -0700	[thread overview]
Message-ID: <20260723154022.GA718817@zen.localdomain> (raw)
In-Reply-To: <a4d55d8d-c512-4e9a-af71-694437f50825@wdc.com>

On Thu, Jul 23, 2026 at 04:02:27PM +0200, Johannes Thumshirn wrote:
> On 7/22/26 9:01 PM, Boris Burkov wrote:
> > Furthermore, I feel like this is actually quite redundant with the whole
> > EBUSY pivot logic.
> > 
> > So for random reclaim writeback, we walk the ebs in index order and skip
> > any not in the active bg if the active bg has dirty ebs. Then we reach
> > the active bg and flush it, submitting everything. Subsequent tries to
> > writeback the non-active will now wait on that submitted IO and
> > ultimately win and get to become active, and do more submission.
> > 
> > But we could save the bother and make things more direct and simple if
> > we just had btree_writepages() always write out the active bg first then
> > the rest. I don't know if we could fully delete the EBUSY, though, maybe
> > there is some racy case where it would still happen a bit, even if
> > mostly it didn't?
> 
> I got a v2 with your comments (and Sashiko's) addressed. I can look into
> that as well, but that feels a bit more involved and we're seeing random
> hangs in our CI system due to these stalled folios and we have one report on
> the list because of the hole -EAGAIN, so I'd like to get it (hot-)fixed
> possibly in this cycle and take care about that once the hotfix is there.
> 
> How does that sound?
> 

100% fine to fix without going crazy removing EBUSY or whatever. Sorry
for holding you up on that, I just found the problem interesting.

All else being equal, I would *prefer* to not have the eb submit loop
totally duplicated even in the short term fix. But again, OK with
whatever you need to land to unbreak things.

Thanks,
Boris

  reply	other threads:[~2026-07-23 15:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22 11:30 [PATCH 0/4] btrfs: zoned: btree inode writeback fixes Johannes Thumshirn
2026-07-22 11:30 ` [PATCH 1/4] btrfs: zoned: flush active metadata block group at btree_writepages() start Johannes Thumshirn
2026-07-22 17:08   ` Boris Burkov
2026-07-22 19:01     ` Boris Burkov
2026-07-23 14:02       ` Johannes Thumshirn
2026-07-23 15:40         ` Boris Burkov [this message]
2026-07-22 11:30 ` [PATCH 2/4] btrfs: zoned: drop stranded dirty metadata on transaction abort Johannes Thumshirn
2026-07-22 11:30 ` [PATCH 3/4] btrfs: zoned: drop stranded dirty metadata buffers at unmount Johannes Thumshirn
2026-07-22 11:30 ` [PATCH 4/4] btrfs: zoned: don't clobber the extent buffer when zeroing it out Johannes Thumshirn

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=20260723154022.GA718817@zen.localdomain \
    --to=boris@bur.io \
    --cc=fdmanana@suse.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.com \
    --cc=wqu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox