On Thu, May 24, 2018 at 06:30:10PM -0300, Daniel Henrique Barboza wrote: > > > 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).
Yes, host blktrace is probably the most important piece of evidence. > > 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. Great. Stefan
signature.asc
Description: PGP signature
