Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/5] btrfs: unify folio dirty flag clearing
Date: Tue, 7 Jul 2026 11:09:03 +0930	[thread overview]
Message-ID: <5185687e-8993-4736-a592-054e2b5be276@suse.com> (raw)
In-Reply-To: <62add3b3ebcea3387c329744102bdf2f8bffda65.1778131118.git.wqu@suse.com>



在 2026/5/7 14:59, Qu Wenruo 写道:
> Currently during folio writeback, we call folio_clear_dirty_for_io()
> before extent_writepage(), which causes folio dirty flag to be cleared,
> but without touching the subpage bitmaps.
> 
> This works fine for the bio submission path, as we always call
> btrfs_folio_clear_dirty() to clear the subpage bitmap.
> 
> But this is far from consistent, thus this patch is going to unify the
> behavior to always use btrfs_folio_clear_dirty() helper to clear both
> folio flag and subpage bitmap.
> 
> This involves:
> 
> - Replace folio_clear_dirty_for_io() with folio_test_dirty()
>    There is only one call site calling folio_clear_dirty_for_io() outside
>    of subpage.c, that's inside extent_write_cache_pages() just before
>    extent_writepage().
> 
[...]
> @@ -2585,7 +2596,7 @@ static int extent_write_cache_pages(struct address_space *mapping,
>   			}
>   
>   			if (folio_test_writeback(folio) ||
> -			    !folio_clear_dirty_for_io(folio)) {
> +			    !folio_test_dirty(folio)) {

This is causing regression related to cachestat() reporting.

On 64K page sized systems, even if we have written back all dirty pages, 
the xarray will still have PAGECACHE_TAG_DIRTY for the folio.

Normally that tag is cleared when calling folio_start_writeback() on a 
non-dirty folio, but it still looks like something is missing between 
clearing the last dirty block and submitting the last dirty block.

Will try to figure out the root cause and get it fixed.

But if the root fix doesn't come in time, I'd revert this only line to 
get the regression fixed first.

Thanks,
Qu

  reply	other threads:[~2026-07-07  1:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-07  5:29 [PATCH 0/5] btrfs: remove folio ordered flag Qu Wenruo
2026-05-07  5:29 ` [PATCH 1/5] btrfs: detect dirty blocks without an ordered extent more reliably Qu Wenruo
2026-05-07  5:29 ` [PATCH 2/5] btrfs: unify folio dirty flag clearing Qu Wenruo
2026-07-07  1:39   ` Qu Wenruo [this message]
2026-05-07  5:29 ` [PATCH 3/5] btrfs: use dirty flag to check if an ordered extent needs to be truncated Qu Wenruo
2026-05-07  5:29 ` [PATCH 4/5] btrfs: remove folio_test_ordered() usage Qu Wenruo
2026-05-07  5:29 ` [PATCH 5/5] btrfs: remove folio ordered flag and subpage bitmap Qu Wenruo
2026-05-12 17:35 ` [PATCH 0/5] btrfs: remove folio ordered flag David Sterba

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=5185687e-8993-4736-a592-054e2b5be276@suse.com \
    --to=wqu@suse.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