Re: [PATCH v2 07/13] ext4: drop extent cache before splitting extent

[Zhang Yi <yi.zhang@huaweicloud.com>]

On 11/28/2025 4:16 PM, Ojaswin Mujoo wrote:
> On Thu, Nov 27, 2025 at 03:27:26PM +0800, Zhang Yi wrote:
>> On 11/26/2025 8:24 PM, Ojaswin Mujoo wrote:
>>> On Fri, Nov 21, 2025 at 02:08:05PM +0800, Zhang Yi wrote:
>>>> From: Zhang Yi <yi.zhang@huawei.com>
>>>>
[...]
>>>>
>>>> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
>>>> index 2b5aec3f8882..9bb80af4b5cf 100644
>>>> --- a/fs/ext4/extents.c
>>>> +++ b/fs/ext4/extents.c
>>>> @@ -3367,6 +3367,12 @@ static struct ext4_ext_path *ext4_split_extent(handle_t *handle,
>>>>  	ee_len = ext4_ext_get_actual_len(ex);
>>>>  	unwritten = ext4_ext_is_unwritten(ex);
>>>>  
>>>> +	/*
>>>> +	 * Drop extent cache to prevent stale unwritten extents remaining
>>>> +	 * after zeroing out.
>>>> +	 */
>>>> +	ext4_es_remove_extent(inode, ee_block, ee_len);
>>>> +
> 
> Okay this makes sense, there are many different combinations of how the
> on disk extents might turn out and if will become complicated to keep
> the es in sync to those, so this seems simpler.
> 
> There might be a small performance penalty of dropping the es here tho
> but idk if it's anything measurable. As a middle ground do you think it
> makes more sense to drop the es cache in ext4_split_extent_at() instead,
> when we know we are about to go for zeroout. Since the default non
> zeroout path seems to be okay?
> 
> Regards,
> ojaswin
> 
> 

Yes, this makes sense to me! I will move it to ext4_split_extent_at()
in my next iteration.

Thanks,
Yi.

> 
>>>>  	/* Do not cache extents that are in the process of being modified. */
>>>>  	flags |= EXT4_EX_NOCACHE;
>>>>  
>>>> -- 
>>>> 2.46.1
>>>>
>>