From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Johannes Thumshirn <johannes.thumshirn@wdc.com>,
Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Cc: Filipe Manana <fdmanana@suse.com>,
Naohiro Aota <naohiro.aota@wdc.com>,
Damien Le Moal <dlemoal@kernel.org>
Subject: Re: [PATCH 2/5] btrfs: zoned: drop stale dirty btree buffers at close_ctree()
Date: Sat, 18 Jul 2026 08:15:08 +0930 [thread overview]
Message-ID: <52e5795e-dd45-4a35-b13f-a53513ae3e7f@gmx.com> (raw)
In-Reply-To: <f19d3f3c-f36c-4fff-a6db-e4b640f6b8e5@wdc.com>
在 2026/7/17 23:47, Johannes Thumshirn 写道:
> On 17.07.26 00:49, Qu Wenruo wrote:
>>
>>
>> 在 2026/7/16 21:26, Johannes Thumshirn 写道:
>>> On a zoned filesystem btrfs_clear_buffer_dirty() keeps a freed-but-dirty
>>> tree block dirty (EXTENT_BUFFER_ZONED_ZEROOUT) so its zero-out keeps the
>>> zone write pointer moving. A block left ahead of the block group's
>>> meta_write_pointer (e.g. a tree-log block freed before being written)
>>> can
>>> never be written by btree_writepages() and survives to unmount.
>>>
>>> close_ctree() stops the endio workqueues before the final iput() of the
>>> btree inode but frees the block groups only afterwards. Once the block
>>> group is gone btrfs_check_meta_write_pointer() no longer defers the
>>> buffer,
>>> so the iput() submits it for writeback; its completion can no longer be
>>> queued on the destroyed endio_meta_workers and umount hangs on writeback
>>> that never finishes.
>>
>> Can we just trigger a btree inode write back for zoned cases?
>>
>> That sounds much simpler and less hacky.
> I tried freeing the stale ebs in btrfs_reset_unused_block_groups()
> before actually resetting the bg, but then the WARN() in
> invalidate_and_check_btree_folios() triggered again. So that doesn't
> work sorry.
>
Sorry I'm not familiar with zoned metadata writeback.
But it still doesn't sound correctly to me.
To me, this seems to be a problem that btrfs_check_meta_write_pointer()
can skip some ebs from being written back, and in that case those ebs
should be properly handled (e.g. clearing dirty etc) but that's not the
case.
Yes, btrfs_clear_buffer_dirty() will not clear the EXTENT_BUFFER_DIRTY
flag, but only set EXTENT_BUFFER_ZEROOUT flag.
But still that dirty eb will go through writeback, as they still have
the folio dirty flag and page cache tags, being properly submitted and
got its EXTENT_BUFFER_DIRTY cleared, in the regular
lock_extent_buffer_for_io() path, then go through the write_one_eb() to
be submitted.
However if btrfs_check_meta_write_pointer() returns non-zero values, we
skip the writeback for that eb completely, so that eb stays dirty forever.
Shouldn't we do something to clean up those ebs in the first place?
So to me, this seems to be a problem in the zoned metadata writeback
behavior, just being exposed by the newly introduced sanity checks.
Thanks,
Qu
next prev parent reply other threads:[~2026-07-17 22:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 11:56 [PATCH 0/5] btrfs: zoned: fix two deadlocks when runing fstests Johannes Thumshirn
2026-07-16 11:56 ` [PATCH 1/5] btrfs: factor out dirty-clearing part of btrfs_clear_buffer_dirty Johannes Thumshirn
2026-07-16 22:31 ` Qu Wenruo
2026-07-16 11:56 ` [PATCH 2/5] btrfs: zoned: drop stale dirty btree buffers at close_ctree() Johannes Thumshirn
2026-07-16 22:49 ` Qu Wenruo
2026-07-17 6:56 ` Johannes Thumshirn
2026-07-17 14:17 ` Johannes Thumshirn
2026-07-17 22:45 ` Qu Wenruo [this message]
2026-07-16 11:56 ` [PATCH 3/5] btrfs: walk waited ordered extents in place Johannes Thumshirn
2026-07-16 11:56 ` [PATCH 4/5] btrfs: walk waited ordered roots " Johannes Thumshirn
2026-07-16 11:56 ` [PATCH 5/5] btrfs: zoned: avoid ordered_operations_mutex when finishing a zone 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=52e5795e-dd45-4a35-b13f-a53513ae3e7f@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dlemoal@kernel.org \
--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