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.zayt...@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.zayt...@gmail.com> Signed-off-by: Stefan Hajnoczi <stefa...@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); } }