All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Wang <xjtuwjp@gmail.com>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Alexey Zaytsev <alexey.zaytsev@gmail.com>,
	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 10:15:31 +0100	[thread overview]
Message-ID: <526E2B33.60907@gmail.com> (raw)
In-Reply-To: <526A87E2.9020705@gmail.com>

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  9:15 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 [this message]
2013-10-28  9:54   ` Alexey Zaytsev
2013-10-28 10:13     ` Jack Wang
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=526E2B33.60907@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.