[Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads

2018-05-15 Thread Daniel Henrique Barboza
Hi, I've been working in the last two months in a miscompare issue that happens when using a raid device and a SATA as scsi-hd (emulated SCSI) with cache=none and io=threads during a hardware stress test. I'll summarize it here as best as I can without creating a great wall of text - Red Hat

Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads

2018-05-16 Thread Paolo Bonzini
On 15/05/2018 23:25, Daniel Henrique Barboza wrote: > This is the current status of this investigation. I decided to start a > discussion here, see if someone can point me something that I overlooked > or got it wrong, before I started changing the POSIX thread pool > behavior to see if I can enfor

Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads

2018-05-24 Thread Stefan Hajnoczi
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

Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads

2018-05-24 Thread Daniel Henrique Barboza
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

Re: [Qemu-block] Problem with data miscompare using scsi-hd, cache=none and io=threads

2018-06-01 Thread Stefan Hajnoczi
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 tha