Re: [PATCH] xfs: fix write failures in software-provided atomic writes

[John Garry <john.g.garry@oracle.com>]

On 30/10/2025 15:01, Darrick J. Wong wrote:
>> As for that corruption, I am seeing the same behaviour as Ojaswin described.
>> The failure is in a read operation.
>>
>> It seems to be a special combo of atomic write, write, and then read which
>> reliably shows the issue. The regular write seems to write to the cow fork,
>> so I am guessing that the atomic write does not leave it in proper state.
>>
>> I do notice for the atomic write that we are writing (calling
>> xfs_atomic_write_cow_iomap_begin() -> xfs_bmapi_write()) for more blocks
>> that are required for the atomic write. The regular write overwrites these
>> blocks, and the read is corrupted in the blocks just after the atomic write.
>> It's as if the blocks just after atomic write are not left in the proper
>> state.
> That's a good breadcrumb for me to follow;

I hope that it is ...

> I will turn on the rmap
> tracepoints to see if they give me a better idea of what's going on.
> I mentioned earlier that I think the problem could be that iomap treats
> srcmap::type == IOMAP_HOLE as if the srcmap isn't there, and so it'll
> read from the cow fork blocks even though that's not right.

Something else I notice for my failing test is that we do the regular 
write, it ends in a sub-fs block write on a hole. But that fs block 
(which was part of a hole) ends up being filled with all the same data 
pattern (when I would expect the unwritten region to be 0s when read 
back) - and this is what the compare fails on.

cheers