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

[Qu Wenruo <wqu@suse.com>]

在 2026/5/6 23:13, David Sterba 写道:
> 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.

I have a better idea now, we can move the ordered extent check into 
alloc_new_bio(), where we're already doing an ordered extent search there.

For now if we failed to find an OE, we continue.

This can be changed to output an error, but will need extra error 
handling if no OE is found.

This will not introduce new OE search, and have a better accuracy than 
the per-folio checks.

Thanks,
Qu

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