Re: [PATCH RFC 0/4] btrfs: remove folio ordered flag

[David Sterba <dsterba@suse.cz>]

On Tue, May 05, 2026 at 09:19:20AM +0930, Qu Wenruo wrote:
> 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.

For debugging and additional verification we can keep it as long as it's
practical.

> 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.

This seems to be a concern for removing the ordered bit, it will have
some performance impact. Searching in rb-tree is not cheap, compared to
a single bit check. This kind of optimization could be there even after
we switch to iomap.

Otherwise, reducing the size of bitmaps makes sense. We could live for a
release with less effective storage just to make sure things work and
then remove ordered bitmap or other optimizations.