Re: [PATCH v2 05/13] generic/1226: Add atomic write test using fio crc check verifier

John Garry
2025-07-03T16:27:07Z

On 03/07/2025 07:42, Ojaswin Mujoo wrote:
>>> Why serialization matters here, because even if device reorders our read
>>> before the atomic write, we still fetch an older $blocksize chunk which
>>> should have the data and the header.
>> Yes, we fetch $blocksize, but it may be as multiple read requests,
>> so we can have:
>>
>> partial read $blocksize request, atomic write request, partial read
>> $blocksize request
> Ahh now I get the picture. Since software atomic writes might have a
> value way higher than the max_sectors that the bio may split at, this
> causes the reads to split which is the issue happnes, as you mentioned.

This issue also exists for atomic writes based on REQ_ATOMIC.

>
>>> The data crc should match the
>>> header because it would have gone atomically. What am I missing?
>>>
>>> (Or do you mean that max_sectors_kb is not big enough to support
>>> reads after software atomic writes and thats the issue?)
>>>
>>>> Can you cap at atomic write unit max opt? That will mean that we get
>>>> serialization from atomic write HW support.
>>>>
>>>> BTW, to repeat what I said before, it can also fail for atomic write bios
>>>> using HW support, as reads may be split.
>>> This one I can understand, the fio's read is split causing a short read
>>> and seems like fio is not requeing short read properly for the verify
>>> step(?) so it tries to verify against short read itself.
>> this is not an fio problem, as above.
> Yep got it, its the block layer splitting the reads.
>
> So as a solution, do you think it is okay to cap $blocksize to
> max_sectors_kb or would you suggest it would be better to just stick to
> awu max opt?

I tend to think that it is better to cap at awu max opt. If zero, then
don't do the test.

What awu max opt is reported for ext4 (for awu max > FS block size)? Is
min(bigalloc size, bdev awu max)?

Thanks,
John