From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH RFC 0/4] btrfs: remove folio ordered flag
Date: Tue, 5 May 2026 09:19:20 +0930 [thread overview]
Message-ID: <cover.1777937175.git.wqu@suse.com> (raw)
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.
But there is a special call site inside btrfs_invalidate_folio() where
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 first patch is
introduced to change the folio dirty flag clearing timing, then the
second patch can remove the folio_test_ordered() usage.
Then the third patch is to remove the remaining folio_test_ordered()
usage, and finally we can remove the whole ordered flag/subpage bitmap
completely.
[REASON FOR RFC]
I'm not sure if we should remove the folio ordered flag completely, or
keep it an internal debug feature for a while.
The main concern is that we're removing quite some ASSERT()s, some are
never hit, but at least one is very useful and had triggered several
times during development, exposing bugs.
In the long run, we will eventually remove the folio ordered
flag/subpage bitmap so that we can align btrfs_folio_state with
iomap_folio_state, so ordered flags should still be gone eventually.
Another point of concern is the new btrfs_ordered_extent_in_range()
helper for extent_writepage_io().
Previously we're just doing a folio flag check, now we have to do an
rbtree search.
I hope the overhead is not that huge.
Qu Wenruo (4):
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 | 35 ++++++++++--------------
fs/btrfs/extent_io.h | 12 ++++++++-
fs/btrfs/fs.h | 8 ------
fs/btrfs/inode.c | 60 ++++++++++-------------------------------
fs/btrfs/ordered-data.h | 16 +++++++++++
fs/btrfs/subpage.c | 41 ++--------------------------
fs/btrfs/subpage.h | 12 +++------
7 files changed, 60 insertions(+), 124 deletions(-)
--
2.54.0
next reply other threads:[~2026-05-04 23:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 23:49 Qu Wenruo [this message]
2026-05-04 23:49 ` [PATCH RFC 1/4] btrfs: unify folio dirty flag clearing Qu Wenruo
2026-05-04 23:49 ` [PATCH RFC 2/4] btrfs: use dirty flag to check if an ordered extent needs to be truncated Qu Wenruo
2026-05-04 23:49 ` [PATCH RFC 3/4] btrfs: remove folio_test_ordered() usage Qu Wenruo
2026-05-04 23:49 ` [PATCH RFC 4/4] btrfs: remove folio ordered flag and subpage bitmap Qu Wenruo
2026-05-06 13:43 ` [PATCH RFC 0/4] btrfs: remove folio ordered flag David Sterba
2026-05-06 21:27 ` 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.1777937175.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