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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Fri, Jun 27, 2025 at 03:09:09PM +0100, John Garry wrote:
> 
> > +touch "$SCRATCH_MNT/f1"
> > +awu_min_write=$(_get_atomic_write_unit_min "$SCRATCH_MNT/f1")
> > +awu_max_write=$(_get_atomic_write_unit_max "$SCRATCH_MNT/f1")
> > +blocksize=$(_max "$awu_min_write" "$((awu_max_write/2))")
> > +
> > +# XFS can have high awu_max_write due to software fallback. Cap it at 64k
> 
> This test fails on xfs due for this reason. software fallback -based atomic
> writes have no serialization against reads or other writes.

Okay so Im still not understanding why serialization is affecting
anything here? Lets assume the IO never breaks, from what I understand
in fio code, we do the write and then once it is complete we try to read
it back and verify it.

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. 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.
> 
> See this sample output:
> 
> generic/1226 68s ... - output mismatch (see
> /home/opc/xfstests-dev/results//generic/1226.out.bad)
>     --- tests/generic/1226.out  2025-06-27 11:26:58.411121674 +0000
>     +++ /home/opc/xfstests-dev/results//generic/1226.out.bad 2025-06-27
> 14:03:08.933811064 +0000
>     @@ -1,2 +1,104 @@
>      QA output created by 1226
>     +crc32c: verify failed at file /home/opc/mnt/scratch/test-file offset
> 16457728, length 8192 (requested block: offset=16457728, length=8192,
> flags=84)
>     +       Expected CRC: 712de900
>     +       Received CRC: f872a18d
>     +crc32c: verify failed at file /home/opc/mnt/scratch/test-file offset
> 88104960, length 8192 (requested block: offset=88104960, length=8192,
> flags=84)
>     +       Expected CRC: 4aaaf009
>     +       Received CRC: 2a5770cf
>     ...
>     (Run 'diff -u /home/opc/xfstests-dev/tests/generic/1226.out
> /home/opc/xfstests-dev/results//generic/1226.out.bad'  to see the entire
> diff)
> Ran: generic/1226
> Failures: generic/1226
> Failed 1 of 1 tests
> 
> [root@jgarry-ol9new xfstests-dev]# cat /sys/block/sdi/queue/max_sectors_kb
> 4
> [root@jgarry-ol9new xfstests-dev]#
> 
> However, nobody should fiddle with max_sectors_kb, so the test still has
> value.
> 
> 
> > +blocksize=$(_min "$blocksize" "65536")
> > +
> > +fio_config=$tmp.fio
> > +fio_out=$tmp.fio.out
> > +




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux