qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jack Wang <xjtuwjp@gmail.com>
To: Alexey Zaytsev <alexey.zaytsev@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [RFC] block io lost in the guest , possible related to qemu?
Date: Mon, 28 Oct 2013 11:13:09 +0100	[thread overview]
Message-ID: <526E38B5.6000105@gmail.com> (raw)
In-Reply-To: <CAB9v_DGUEHsP=XuxRgetcaz79gWSXA7S3NDY32mrioiZTZX52g@mail.gmail.com>

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_UNSUPP).

Hi Alexey,

Thanks for you input.
According to my test results, yes, as you said, virtio-blk never
generate wrong request type. So the commit is only a small cosmetic
extra check:(

As there's nothing abnormal in host server and storage, there must be
some hidden bug somewhere, damn it.

Regards,
Jack



> 
> On Mon, Oct 28, 2013 at 10:15 AM, Jack Wang <xjtuwjp@gmail.com> wrote:
>> 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 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 lot requests is lost in below storage
>>> stack.
>>>
>>> We're use qemu-kvm 1.0, host kernel 3.4.51
>>>
>>> In qemu log of virtio-blk.c
>>> I found below commit, I wonder is it possible the workload generate some
>>> unknown reqests to qemu that lost in virtio_blk_handle_read?
>>> I do some fio test myself, I cann't generate so call unknown request type.
>>>
>>> Any response will be helpful.
>>>
>>> Jack
>>>
>>>
>>> commit 9e72c45033770b81b536ac6091e91807247cc25a
>>> Author: Alexey Zaytsev <alexey.zaytsev@gmail.com>
>>> Date:   Thu Dec 13 09:03:43 2012 +0200
>>>
>>>     virtio-blk: Return UNSUPP for unknown request types
>>>
>>>     Currently, all unknown requests are treated as VIRTIO_BLK_T_IN
>>>
>>>     Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
>>>     Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
>>>
>>> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
>>> index 92c745a..df57b35 100644
>>> --- a/hw/virtio-blk.c
>>> +++ b/hw/virtio-blk.c
>>> @@ -398,10 +398,14 @@ static void
>>> virtio_blk_handle_request(VirtIOBlockReq *req,
>>>          qemu_iovec_init_external(&req->qiov, &req->elem.out_sg[1],
>>>                                   req->elem.out_num - 1);
>>>          virtio_blk_handle_write(req, mrb);
>>> -    } else {
>>> +    } else if (type == VIRTIO_BLK_T_IN || type == VIRTIO_BLK_T_BARRIER) {
>>> +        /* VIRTIO_BLK_T_IN is 0, so we can't just & it. */
>>>          qemu_iovec_init_external(&req->qiov, &req->elem.in_sg[0],
>>>                                   req->elem.in_num - 1);
>>>          virtio_blk_handle_read(req);
>>> +    } else {
>>> +        virtio_blk_req_complete(req, VIRTIO_BLK_S_UNSUPP);
>>> +        g_free(req);
>>>      }
>>>  }
>>>
>>

  reply	other threads:[~2013-10-28 10:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25 15:01 [Qemu-devel] [RFC] block io lost in the guest , possible related to qemu? Jack Wang
2013-10-28  9:15 ` Jack Wang
2013-10-28  9:54   ` Alexey Zaytsev
2013-10-28 10:13     ` Jack Wang [this message]
2013-10-30  9:50 ` Stefan Hajnoczi
2013-10-30 10:55   ` Jack Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=526E38B5.6000105@gmail.com \
    --to=xjtuwjp@gmail.com \
    --cc=alexey.zaytsev@gmail.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).