From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDIUa-0003jA-MM for qemu-devel@nongnu.org; Wed, 06 Mar 2013 12:51:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDIUV-0004C5-DG for qemu-devel@nongnu.org; Wed, 06 Mar 2013 12:51:04 -0500 Received: from ssl.dlhnet.de ([91.198.192.8]:60760 helo=ssl.dlh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDIUV-0004Aw-6G for qemu-devel@nongnu.org; Wed, 06 Mar 2013 12:50:59 -0500 Message-ID: <51378200.5010705@dlhnet.de> Date: Wed, 06 Mar 2013 18:50:56 +0100 From: Peter Lieven MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/7] block: only force IO completion in .bdrv_truncate if we are shrinking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: kwolf@redhat.com, sw@weilnetz.de, qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com Am 06.03.2013 15:47, schrieb Jeff Cody: > Commit 9a665b2b made bdrv_truncate() call bdrv_drain_all(), but this breaks > QCOW images, as well other future image formats (such as VHDX) that may call > bdrv_truncate(bs->file) from within a read/write operation. For example, QCOW > will cause an assert, due to tracked_requests not being empty (since the > read/write that called bdrv_truncate() is still in progress). > > This modifies the check to only force the bdrv_drain_all() call if the BDS to > be truncated is not growable, or if we are shrinking the BDS. Otherwise, if we > are just growing the file, allow it to happen without forcing a call to > bdrv_drain_all(). This will actually break iscsi_truncate(). Paolo requested that the iscsi_tuncate command should use sync I/O for rereading the LUN capacity. Using sync I/O is only possible if there are no async requests in-flight. Looking at the source I have not found a place where bs->growable is set to 0 for any block driver, maybe I miss something. Having bs->growable for iSCSI would also be ok. Shouldn't it be possible to call bdrv_drain_all() any time? There are other places where this is called. One I have in mind is e.g. if you cancel an ongoing block migration. Peter > > Signed-off-by: Jeff Cody > --- > block.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/block.c b/block.c > index 124a9eb..dce844c 100644 > --- a/block.c > +++ b/block.c > @@ -2450,8 +2450,14 @@ int bdrv_truncate(BlockDriverState *bs, int64_t offset) > if (bdrv_in_use(bs)) > return -EBUSY; > > - /* There better not be any in-flight IOs when we truncate the device. */ > - bdrv_drain_all(); > + /* Don't force a drain if we are just growing the file - otherwise, > + * using bdrv_truncate() from within a block driver in a read/write > + * operation will cause an assert, because bdrv_drain_all() will assert if > + * a tracked_request is still in progress. */ > + if (!bs->growable || offset < bdrv_getlength(bs)) { > + /* There better not be any in-flight IOs when we truncate the device. */ > + bdrv_drain_all(); > + } > > ret = drv->bdrv_truncate(bs, offset); > if (ret == 0) { >