Heh, here comes that feature naming confusing again. This is myHey Darrick, John,
definition:
RWF_ATOMIC means the system won't introduce new tearing when persisting
file writes. The application is allowed to introduce tearing by writing
to overlapping ranges at the same time. The system does not isolate
overlapping reads from writes.
--D
So seems like my expectations of RWF_ATOMIC were a bit misplaced. I
understand now that we don't really guarantee much when there are
overlapping parallel writes going on. Even 2 overlapping RWF_ATOMIC
writes can get torn. Seems like there are some edge cases where this
might happen with hardware atomic writes as well.
In that sense, if this fio test is doing overlapped atomic io and
expecting them to be untorn, I don't think that's the correct way to
test it since that is beyond what RWF_ATOMIC guarantees.
I'll try to check if we can modify the tests to write on non-overlapping
ranges in a file.