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

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.

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.

--
Pankaj