On 10/30/2013 10:50 AM, Stefan Hajnoczi wrote:
> On Fri, Oct 25, 2013 at 05:01:54PM +0200, Jack Wang wrote:
>> We've seen guest block io lost in a VM.any response will be helpful
>>
>> environment is:
>> guest os: Ubuntu 1304
>> running busy database workload with xfs on a disk export with virtio-b
On Fri, Oct 25, 2013 at 05:01:54PM +0200, Jack Wang wrote:
> We've seen guest block io lost in a VM.any response will be helpful
>
> environment is:
> guest os: Ubuntu 1304
> running busy database workload with xfs on a disk export with virtio-blk
>
> the exported vdb has very high infight io ove
Hey.
I very much doubt this commit could be causing the problem, as qemu
would never set wrong request type in the first place. You can easily
check by either reverting it, or adding a printk() before
virtio_blk_req_complete(VIRTIO_BLK_S_UNSUPP).
On Mon, Oct 28, 2013 at 10:15 AM, Jack Wang wrote
On 10/28/2013 10:54 AM, Alexey Zaytsev wrote:
> Hey.
>
> I very much doubt this commit could be causing the problem, as qemu
> would never set wrong request type in the first place. You can easily
> check by either reverting it, or adding a printk() before
> virtio_blk_req_complete(VIRTIO_BLK_S_UN
Hello Kevin & Stefan
Any comments or wild guess about the bug?
Regards,
Jack
On 10/25/2013 05:01 PM, Jack Wang wrote:
> Hi Experts,
>
> We've seen guest block io lost in a VM.any response will be helpful
>
> environment is:
> guest os: Ubuntu 1304
> running busy database workload with xfs on a
Hi Experts,
We've seen guest block io lost in a VM.any response will be helpful
environment is:
guest os: Ubuntu 1304
running busy database workload with xfs on a disk export with virtio-blk
the exported vdb has very high infight io over 300. Some times later a
lot io process in D state, looks a