From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/5] btrfs: remove folio ordered flag
Date: Thu, 7 May 2026 14:59:16 +0930 [thread overview]
Message-ID: <cover.1778131118.git.wqu@suse.com> (raw)
[CHANGELOG]
RFC->v1:
- Replace the folio_test_ordered() inside extent_writepage_io()
Now do the check inside alloc_new_bio(), which is already doing the OE
search.
Now we can detect dirty blocks without an OE at per-block level, much
better than the previous per-folio level checks, and without any extra
overhead.
Btrfs has a long history using an internal folio flag called ordered,
which is to indicate if an fs block is covered by an ordered extent.
However this means we need to synchronize between ordered extents, which
are managed by a per-inode ordered tree, and folio flag/subpage bitmap.
Furthermore with huge folio support, the ordered bitmap can be as large
as 64 bytes (512 bits), which is not a small amount.
The series is going to remove folio ordered flag completely, along with
the ordered subpage bitmap.
Most call sites of folio_test_ordered() are just inside ASSERT()s, so
it's not too hard to remove them.
There are two call sites that utilizing *_folio_test_ordered():
- Inside extent_writepage_io()
The warning left by the legacy COW fixup mechanism.
The 1st patch is to introduce a more reliable way to detect dirty
blocks without an OE, other than checking the folio ordered flag, now
it's doing a per-block level check without introducing new overhead.
- Inside btrfs_invalidate_folio()
We use ordered flag to check if we can skip an ordered extent.
This is worked around by using the fact that we have waited for
writeback of the folio, so that endio should have already finished for
the writeback range. Then check dirty flags to determine if we can skip
the OE range.
To get a reliable dirty flag for both sub-folio and full-folio cases, we
can not clear the folio dirty flag early, so the 2nd patch is
introduced to change the folio dirty flag clearing timing, then the
3rd patch can remove the folio_test_ordered() usage.
Then the 4th patch is to remove the remaining folio_test_ordered()
usage, and finally we can remove the whole ordered flag/subpage bitmap
completely.
I tried to hide the ordered flag/bitmap behind DEBUG, but unfortunately
the subpage bitmap macros are not that easy to be tweaked to handle
conditional ordered flags.
So the ordered flag/bitmap must be either there, or be completely gone.
I hope enough test runs will cover the removed ASSERT()s.
Qu Wenruo (5):
btrfs: detect dirty blocks without an ordered extent more reliably
btrfs: unify folio dirty flag clearing
btrfs: use dirty flag to check if an ordered extent needs to be
truncated
btrfs: remove folio_test_ordered() usage
btrfs: remove folio ordered flag and subpage bitmap
fs/btrfs/extent_io.c | 117 ++++++++++++++++++++++++-------------------
fs/btrfs/extent_io.h | 12 ++++-
fs/btrfs/fs.h | 8 ---
fs/btrfs/inode.c | 60 ++++++----------------
fs/btrfs/subpage.c | 41 +--------------
fs/btrfs/subpage.h | 19 +++----
6 files changed, 100 insertions(+), 157 deletions(-)
--
2.54.0
next reply other threads:[~2026-05-07 5:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 5:29 Qu Wenruo [this message]
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-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
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=cover.1778131118.git.wqu@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