Re: [PATCH v4 08/23] ext4: implement buffered write path using iomap

[Zhang Yi]

On 6/2/2026 6:05 PM, Ojaswin Mujoo wrote:
> On Fri, May 29, 2026 at 05:13:55PM +0800, Zhang Yi wrote:
>> Hi, Ojaswin!
>>
>> On 5/27/2026 1:10 AM, Ojaswin Mujoo wrote:
>>> On Mon, May 11, 2026 at 03:23:28PM +0800, Zhang Yi wrote:
>>>> From: Zhang Yi <yi.zhang@xxxxxxxxxx>
>>>>
>>>> Introduce two new iomap_ops instances for ext4 buffered writes:
>>>>
>>>>  - ext4_iomap_buffered_da_write_ops: for delayed allocation mode, using
>>>>    ext4_da_map_blocks() to map delalloc extents.
>>>>  - ext4_iomap_buffered_write_ops: for non-delayed allocation mode, using
>>>>    ext4_iomap_get_blocks() to directly allocate blocks.
>>>>
>>>> Also add ext4_iomap_valid() for the iomap infrastructure to check extent
>>>> validity.
>>>>
>>>> Key changes and considerations:
>>>>
>>>>  - Unwritten extents for new blocks (dioread_nolock always on)
>>>>    Since data=ordered mode is not used to prevent stale data exposure in
>>>>    the non-delayed allocation path, new blocks are always allocated as
>>>>    unwritten extents.
>>>
>>> Okay makes sense.
>>>
>>>>
>>>>  - Short write and write failure handling
>>>>    a. Delalloc path: On short write or failure, the stale delalloc range
>>>>       must be dropped and its space reservation released. Otherwise, a
>>>>       clean folio may cover leftover delalloc extents, causing
>>>>       inaccurate space reservation accounting.
>>>
>>> Hmm, okay so in the usual buffer head path, seems like during a short
>>> write we still zero the new buffers we couldn't write and keep it dirty
>>> (folio_zero_new_buffers()). This way they are still written back and
>>> the delalloc reservations are used up.
>>>
>>
>> In fact, in the normal buffer head path, writeback does not consume
>> delalloc reservations. Instead, the reservations are retained until the
>> inode is released or the area is written again using delalloc. This is
>> because i_size is not updated during short writes. Therefore, when a
>> zeroed dirty folio is written back, no block mapping is created for it.
>> For details, please see the lblk >= blocks judgment in
>> mpage_process_page_bufs().
> 
> Oh okay I see, I'm not very clear on the code path but what about a case
> where i_size is beyond the short write range.
> 

Yeah, You're right. When i_size extends beyond the short write range,
the delalloc reservation will be consumed during writeback.

Thanks,
Yi.