Re: [PATCH] generic/795: add unaligned boundary test cases for WRITE_ZEROES

On 7/8/2026 9:21 PM, Pankaj Raghav wrote:
> 
> 
> On 7/7/26 08:38, Zhang Yi wrote:
>> On 7/7/2026 1:10 PM, Christoph Hellwig wrote:
>>> On Tue, Jul 07, 2026 at 11:08:39AM +0800, Zhang Yi wrote:
>>>>> +# WRITE_ZEROES must leave the whole requested range backed by *written*
>>>>> +# (zeroed) extents while preserving the out-of-range bytes of the partial
>>>>> +# boundary units. The possible scenarios are: written_edges, hole_edges,
>>>>> +# unwritten_edges and delalloc_edges.
>>>>
>>>> unwritten_edges needs to distinguish between dirty and clean scenarios.
>>>> The expected result for clean should be tmp.zero, while the expected
>>>> result for dirty should be tmp.pattern.
>>>
>>> Does it?  I'd expect everything in the range to be zeroed, and everything
>>> outside to be left alone, as the dirty state is just an imlementation
>>> detail not visible to the user.
>>
>> Yes, although this detail is not perceptible to the user, the final
>> results of these two scenarios are different.
>>
>> For clean unwritten extents, the portion beyond the range up to the
>> aligned block boundary should be zeroed; otherwise, stale data may be
>> exposed after unwritten-to-written conversion. So the result should
>> be tmp.zero.
>>
>> For dirty unwritten extents, all data outside the inode boundary
>> should be left untouched, so the result should be tmp.pattern.
>>
>>> Similar to other falloc operations,
>>> I'd expect the file system to write back any boundary block first
>>> to make the dirty state difference moot.
>>>
>>
>> In fact, in ext4, for dirty extents (including both dirty delalloc and
>> dirty unwritten extents), they are not written back first. Instead, the
>> unaligned boundary blocks are zeroed out directly, followed by a
>> synchronous write-back before the syscall returns, ensuring the extents
>> are converted to the written state. This point differs from the behavior
>> of XFS.
>>
> 
> I had a similar question as Christoph. But I will include dirty unwritten
> test case as well, as ext4 impl may slightly differ.
> 
> Thanks for the point about the FIEMAP. I will change it to use filefrag.
> 
> I will send the patches soon.

Thank you!

> 
> Btw, I tested ext4 and it failed the test. I assume there is a fix on the way for ext4? And did you
> also test this for bigalloc configuration? I ran into some issues with bigrtalloc (alloc size >
> block size). I am wondering if you hit a similar issue in ext4 for biglloc configs.
> 

Yes, there are issues in the current ext4 that need to be fixed, and I
have already sent out the fixed patch set [1]. I have run several
rounds of this test on my machine, including bigalloc scenarios, and
everything looks fine by now.

After applying this patch set, does the issue you encountered still
exist?

Thanks,
Yi.

[1] https://lore.kernel.org/linux-ext4/[email protected]/