[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads |
Date: |
Fri, 1 Jun 2018 12:49:22 +0100 |
User-agent: |
Mutt/1.9.5 (2018-04-13) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads,
Stefan Hajnoczi <=