Re: [PATCH v7 1/6] btrfs: add delayed ordered extent support

[Qu Wenruo <wqu@suse.com>]

在 2026/9/25 19:02, Miquel Sabaté Solà 写道:
> Qu Wenruo @ 2026-09-25 18:37 +0930:
> 
>> A delayed ordered extent has the following features:
>>
>> - A new BTRFS_ORDERED_DELAYED flag
>>    And this new flag must be set along with the BTRFS_ORDERED_REGULAR flag.
>>
>> - No allocation of any on-disk space
>>    As a delayed ordered extent doesn't take any on-disk space yet, it
>>    won't release any reserved data/meta space either.
>>
>> - Zero or more real OEs can be added to the parent
>>    If a real OE is allocated, it must be inside the parent OE.
>>    And such real OE will go through the regular data/meta space
>>    reservation path.
>>
>> - Child OEs will not be added to the per-inode OE rb-tree nor
>>    per-root list
>>    Only the parent OE is added to the per-inode rb-tree and per-root
>>    list.
>>    So anything waiting for ordered extents should only work on the parent
>>    one.
>>
>>    There is a special corner case for btrfs_wait_ordered_extents(), as
>>    delayed parent OEs have 0 disk_bytenr and disk_num_bytes, they will
>>    be considered out of the [0, U64_MAX] range.
>>    Thus we have to always wait for any delayed OEs of a root, no matter
>>    if a block group range is given or not.
>>
>> - When the parent OE finishes, all child OEs will also be finished
>>    And reserved space is all handled by the child OEs.
>>
>> - Any range not covered by a child OE will be manually cleaned up
>>    When adding a child OE to the parent one, the range in
>>    child_cleanup_bitmap will be cleared.
>>
>>    If a range is already cleaned up but without a child OE (happens when
>>    OE allocation failed), whoever cleans up the range should clear the bits
>>    in the child_cleanup_bitmap.
>>
>>    And when the parent OE finishes, any range in child_cleanup_bitmap
>>    will be properly cleaned up.
>>
>> The above features allow us to use the existing ordered extent interfaces
>> to allocate new real OEs, and wait for them properly.
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   fs/btrfs/inode.c        |  86 ++++++++++++++++++-
>>   fs/btrfs/ordered-data.c | 185 ++++++++++++++++++++++++++++++----------
>>   fs/btrfs/ordered-data.h |  20 +++++
>>   3 files changed, 243 insertions(+), 48 deletions(-)
>>
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index 2a32072849cb..e9ed3e31fa88 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -3204,6 +3204,81 @@ static int insert_ordered_extent_file_extent(struct btrfs_trans_handle *trans,
>>   					   update_inode_bytes, oe->qgroup_rsv);
>>   }
>>
>> +static int finish_delayed_ordered(struct btrfs_ordered_extent *oe)
>> +{
>> +	struct btrfs_inode *inode = oe->inode;
>> +	struct btrfs_fs_info *fs_info = inode->root->fs_info;
>> +	struct btrfs_ordered_extent *child;
>> +	struct btrfs_ordered_extent *tmp;
>> +	struct extent_state *cached = NULL;
>> +	const u32 nr_bits = oe->num_bytes >> fs_info->sectorsize_bits;
>> +	bool io_error = test_bit(BTRFS_ORDERED_IOERR, &oe->flags);
> 
> I believe this one can be made "const", right?

This is a very minor one, I can do it during merge.