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

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

On 11/07/2025 11:39, Ojaswin Mujoo wrote:
>> I don't think that fio supports such a mode. Or does it?
> Yes we can achieve it via combination of write job with verify=crc,do_verify=0 followed by
> verify job with verify=crc,verify_only=1. 

So does verify=crc,do_verify=0 really omit the verify and only do write? 
If so, seems good.

> I'm testing this right now to
> see if it can survive max_sectors_kb = 4 (which i think it should since
> there are no races now). If everything is fine I'll use this approach
> for the fio tests in the next revision.

understood

>>> Yes, it is a bit less effective but
>>> then having a data integrity test that can theoretically return false
>>> positives is not good, it'll always keep me guessing about any failure.
>>> Having verify at end will not have false failures for sure. Even though
>>> it comes at a cost of less coverage.
>>>
>>> Maybe we can also get some other prespectives on this.
>>> @Zorro, @Darrick, can you please give your thoughts on this?
>>>
>>> As a sidenote, with this issue of fio's verify read splitting, it seems
>>> like the parallel verify feature in fio itself is flawed for non-atomic
>>> writes as well since the read can always split and race with the writes.
>> fio does warn that multiple read and writers in verify mode is unsafe.
> Right.
> 
>>> Not sure what the solution is here, maybe time for non splittable atomic
>>> writes (:p)
>> I just think that fio in verify mode for ext4 is ok, as long as
>> max_sectors_kb is large.
> Yes but i'd rather have the write followed by verify version to avoid
> false positives in case the read bio does end up splitting for whatever
> reason.
> 
> Thanks for catching this issue in the test!

So, if you want to test this way then you need to omit xfs or ensure 
that the bs <= awu max opt for xfs and hope for no problems.

Thanks,
John