qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC] block io lost in the guest , possible related to qemu


From: Jack Wang
Subject: [Qemu-devel] [RFC] block io lost in the guest , possible related to qemu?
Date: Fri, 25 Oct 2013 17:01:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4

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 <address@hidden>
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 <address@hidden>
    Signed-off-by: Stefan Hajnoczi <address@hidden>

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 via email to

[Prev in Thread] Current Thread [Next in Thread]