From patchwork Wed Sep 23 12:04:25 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Wolf X-Patchwork-Id: 521668 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 84B76140187 for ; Wed, 23 Sep 2015 22:04:56 +1000 (AEST) Received: from localhost ([::1]:47420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zein8-0003mm-K1 for incoming@patchwork.ozlabs.org; Wed, 23 Sep 2015 08:04:54 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zeimn-0003VT-9D for qemu-devel@nongnu.org; Wed, 23 Sep 2015 08:04:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zeimj-0006B7-7y for qemu-devel@nongnu.org; Wed, 23 Sep 2015 08:04:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zeimj-0006B1-26 for qemu-devel@nongnu.org; Wed, 23 Sep 2015 08:04:29 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 2D35B2F9113; Wed, 23 Sep 2015 12:04:28 +0000 (UTC) Received: from noname.redhat.com (ovpn-116-104.ams2.redhat.com [10.36.116.104]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t8NC4Qik011360; Wed, 23 Sep 2015 08:04:26 -0400 Date: Wed, 23 Sep 2015 14:04:25 +0200 From: Kevin Wolf To: Guangmu Zhu Message-ID: <20150923120425.GB4557@noname.redhat.com> References: <20150922150718.GI3999@noname.str.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: qemu-devel Subject: Re: [Qemu-devel] No error report when using the qemu-img.exe toconvert a disk to vmdk format which is saved on a disk that has no morespace X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Am 23.09.2015 um 13:30 hat Guangmu Zhu geschrieben: > If the "BlockDriver" is "bdrv_vmdk", the function "vmdk_co_write" will be > called instead. In function "vmdk_write_extent" I see "ret = bdrv_pwrite > (extent->file, write_offset, write_buf, write_len);". So the "extend->file" is > "bdrv_file", is it? Yes, exactly. You'll go through bdrv_vmdk first, and then the nested call goes to bdrv_file. > ------------------------------------------------- > > Correct a mistake: > So though the "count" would be "-EINVAL" if error occurred while writing some > file, the return value will always be zero. Maybe I missed something? I think you're right. Instead of setting count = 0/-EINVAL in aio_worker, we should be setting ret. Can you try the patch below and report back? > 3. The "bs->drv->bdrv_aio_writev" is function "raw_aio_writev" in file > "raw-win32.c" and the quemu-img uses synchronous IO always, so the function > "paio_submit" in the same file will be called. This function submits the "aio" > to "worker_thread" with the callback "aio_worker". There are some codes in > "aio_worker": > > ssize_t ret = 0; > ...... > case QEMU_AIO_WRITE: > count = handle_aiocb_rw(aiocb); > if (count == aiocb->aio_nbytes) { > count = 0; > } else { > count = -EINVAL; > } > break; > ...... > return ret; Independently of your problem, the code in aio_worker() looks a bit fishy, because handle_aiocb_rw() can't distinguish between an error and 0 bytes transferred. For writes, that probably doesn't matter, but for reads, I think we return a successful read of zeroes instead of signalling an error. This might need another patch. Generally, the Windows backend is not getting a lot of attention and could use someone who checks it, cleans it up and fixes bugs. Kevin diff --git a/block/raw-win32.c b/block/raw-win32.c index 68f2338..b562c94 100644 --- a/block/raw-win32.c +++ b/block/raw-win32.c @@ -119,9 +119,9 @@ static int aio_worker(void *arg) case QEMU_AIO_WRITE: count = handle_aiocb_rw(aiocb); if (count == aiocb->aio_nbytes) { - count = 0; + ret = 0; } else { - count = -EINVAL; + ret = -EINVAL; } break; case QEMU_AIO_FLUSH: