From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vajp3-0005kv-Ny for qemu-devel@nongnu.org; Mon, 28 Oct 2013 06:13:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vajov-0001Aq-2o for qemu-devel@nongnu.org; Mon, 28 Oct 2013 06:13:21 -0400 Received: from mail-bk0-x22e.google.com ([2a00:1450:4008:c01::22e]:50767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vajou-0001Aa-Ra for qemu-devel@nongnu.org; Mon, 28 Oct 2013 06:13:13 -0400 Received: by mail-bk0-f46.google.com with SMTP id w17so237068bkz.33 for ; Mon, 28 Oct 2013 03:13:11 -0700 (PDT) Message-ID: <526E38B5.6000105@gmail.com> Date: Mon, 28 Oct 2013 11:13:09 +0100 From: Jack Wang MIME-Version: 1.0 References: <526A87E2.9020705@gmail.com> <526E2B33.60907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] block io lost in the guest , possible related to qemu? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Zaytsev Cc: Kevin Wolf , qemu-devel , Stefan Hajnoczi 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 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 >>> 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 >>> Signed-off-by: Stefan Hajnoczi >>> >>> 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); >>> } >>> } >>> >>