On 2024/12/4 19:52, Jan Kara wrote:
> On Tue 22-10-24 19:10:36, Zhang Yi wrote:
>> From: Zhang Yi <yi.zhang@xxxxxxxxxx>
>>
>> The current implementation of ext4_zero_range() contains complex
>> position calculations and stale error tags. To improve the code's
>> clarity and maintainability, it is essential to clean up the code and
>> improve its readability, this can be achieved by: a) simplifying and
>> renaming variables, making the style the same as ext4_punch_hole(); b)
>> eliminating unnecessary position calculations, writing back all data in
>> data=journal mode, and drop page cache from the original offset to the
>> end, rather than using aligned blocks; c) renaming the stale out_mutex
>> tags.
>>
>> Signed-off-by: Zhang Yi <yi.zhang@xxxxxxxxxx>
>
> ...
>
>> - goto out_mutex;
>> -
>> - /* Preallocate the range including the unaligned edges */
>> - if (partial_begin || partial_end) {
>> - ret = ext4_alloc_file_blocks(file,
>> - round_down(offset, 1 << blkbits) >> blkbits,
>> - (round_up((offset + len), 1 << blkbits) -
>> - round_down(offset, 1 << blkbits)) >> blkbits,
>> - new_size, flags);
>> - if (ret)
>> - goto out_mutex;
>> -
>> - }
>
> So I think we should keep this first ext4_alloc_file_blocks() call before
> we truncate the page cache. Otherwise if ext4_alloc_file_blocks() fails due
> to ENOSPC, we have already lost the dirty data originally in the zeroed
> range. All the other failure modes are kind of catastrophic anyway, so they
> are fine after dropping the page cache. But this is can be quite common and
> should be handled more gracefully.
>
Ha, right, I missed this error case, I will revise it.
Thanks,
Yi.
