On 05/24/2018 11:04 AM, Stefan Hajnoczi wrote:
On Tue, May 15, 2018 at 06:25:46PM -0300, Daniel Henrique Barboza wrote:
This means that the test executed a write at LBA 0x94fa and, after
confirming that the write was completed, issue 2 reads in the same LBA to
assert the written contents and found out a mismatch.
Have you confirmed this pattern at various levels in the stack:
1. Application inside the guest (strace)
2. Guest kernel block layer (blktrace)
3. QEMU (strace)
4. Host kernel block layer (blktrace)
Tested (3). In this case the bug stop reproducing. Not sure if there is
anything related with strace adding a delay back and forth the
preadv/pwritev calls, but the act of attaching strace to the QEMU
process changed the behavior.
Haven't tried the other 3 scenarios. (2) and (4) are definitely worth
trying it
out, specially (4).
The key thing is that the write completes before the 2 reads are
submitted.
Have you tried running the test on bare metal?
Yes. The stress test does not reproduce the miscompare issue when
running on bare metal.
Thanks,
Daniel
Stefan
