On 05/09/2024 10:37, Luis Chamberlain wrote:
Sorry for the slow response. For some reason I did not receive this
mail. I just downloaded from lore now.
On Thu, Aug 29, 2024 at 12:31:00PM +0000, John Garry wrote:
The verify feature can be useful to prove atomic writes. However, atomic
writes only ensure a proper CRC, but not sequence number. So sequence
numbers are ignored in verify mode for atomic writes.
How fio verify mode works is that we write datablocks to the file with a
CRC and sequence number per block. When verifying, we check the expected
sequence number and embedded CRC per block - if not as expected, we
error. This should not happen for a single job.
However, if we have multiple jobs, they may overwrite blocks from other
jobs - fio warns us about that. As such, in verify mode, the read
sequence number may not match was we were expecting with multiple jobs
running. In normal non-atomic write verify mode, the CRC may also be
incorrect, as we may see partially written blocks.
However, in atomic write verify mode, the CRC should be good with
multiple jobs, as we won't see a partial write. The data may not
actually be what we wrote - hence the possible incorrect sequence number
- but the CRC itself should be ok.
Why not? Note that NVMe TP4098 MAM support (not public yet I think so
I'm not going into details)
This is not related to MAM, and really an fio feature.
is outside of scope as the current
RWF_ATOMIC requirements specifically require natural alignment and for
the writes to be between stx_atomic_write_unit_min (LBA format) and
stx_atomic_write_unit_max (AWUPF) -- why are we not getting sequence
numbers right? Is that a SCSI issue?
This is related to how fio verify mode works, and not related to SCSI or
NVMe.
cheers,
John
