From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROn5Q-0001Mo-DE for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:07:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROn5P-00053l-9t for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:07:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROn5P-00053e-0d for qemu-devel@nongnu.org; Fri, 11 Nov 2011 04:07:47 -0500 Message-ID: <4EBCE69C.7060804@redhat.com> Date: Fri, 11 Nov 2011 10:10:52 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1320946336-17688-1-git-send-email-kwolf@redhat.com> <1320946336-17688-3-git-send-email-kwolf@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 2/3] block: Introduce bdrv_co_flush_to_os List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Yong Wu Cc: pbonzini@redhat.com, qemu-devel@nongnu.org Am 11.11.2011 05:06, schrieb Zhi Yong Wu: > On Fri, Nov 11, 2011 at 1:32 AM, Kevin Wolf wrote: >> qcow2 has a writeback metadata cache, so flushing a qcow2 image actually >> consists of writing back that cache to the protocol and only then flushes the >> protocol in order to get everything stable on disk. >> >> This introduces a separate bdrv_co_flush_to_os to reflect the split. >> >> Signed-off-by: Kevin Wolf >> --- >> block.c | 13 ++++++++++++- >> block/qcow2.c | 10 ++++++++-- >> block_int.h | 7 +++++++ >> 3 files changed, 27 insertions(+), 3 deletions(-) >> >> diff --git a/block.c b/block.c >> index d3042da..f81dd9f 100644 >> --- a/block.c >> +++ b/block.c >> @@ -2782,11 +2782,22 @@ static void coroutine_fn bdrv_flush_co_entry(void *opaque) >> >> int coroutine_fn bdrv_co_flush(BlockDriverState *bs) >> { >> + int ret; >> + >> if (bs->open_flags & BDRV_O_NO_FLUSH) { >> return 0; >> } else if (!bs->drv) { >> return 0; >> - } else if (bs->drv->bdrv_co_flush_to_disk) { >> + } >> + >> + if (bs->drv->bdrv_co_flush_to_os) { >> + ret = bs->drv->bdrv_co_flush_to_os(bs); >> + if (ret < 0) { >> + return ret; >> + } >> + } >> + >> + if (bs->drv->bdrv_co_flush_to_disk) { >> return bs->drv->bdrv_co_flush_to_disk(bs); >> } else if (bs->drv->bdrv_aio_flush) { >> BlockDriverAIOCB *acb; >> diff --git a/block/qcow2.c b/block/qcow2.c >> index f7f73fe..5c784ee 100644 >> --- a/block/qcow2.c >> +++ b/block/qcow2.c >> @@ -1105,7 +1105,7 @@ fail: >> return ret; >> } >> >> -static int qcow2_co_flush(BlockDriverState *bs) >> +static int qcow2_co_flush_to_os(BlockDriverState *bs) >> { >> BDRVQcowState *s = bs->opaque; >> int ret; >> @@ -1124,6 +1124,11 @@ static int qcow2_co_flush(BlockDriverState *bs) >> } >> qemu_co_mutex_unlock(&s->lock); >> >> + return 0; >> +} >> + >> +static int qcow2_co_flush_to_disk(BlockDriverState *bs) >> +{ >> return bdrv_co_flush(bs->file); >> } >> >> @@ -1245,7 +1250,8 @@ static BlockDriver bdrv_qcow2 = { >> >> .bdrv_co_readv = qcow2_co_readv, >> .bdrv_co_writev = qcow2_co_writev, >> - .bdrv_co_flush_to_disk = qcow2_co_flush, >> + .bdrv_co_flush_to_os = qcow2_co_flush_to_os, >> + .bdrv_co_flush_to_disk = qcow2_co_flush_to_disk, >> >> .bdrv_co_discard = qcow2_co_discard, >> .bdrv_truncate = qcow2_truncate, >> diff --git a/block_int.h b/block_int.h >> index 5aadc1f..1ec4921 100644 >> --- a/block_int.h >> +++ b/block_int.h >> @@ -93,6 +93,13 @@ struct BlockDriver { >> */ >> int coroutine_fn (*bdrv_co_flush_to_disk)(BlockDriverState *bs); >> >> + /* >> + * Flushes all internal caches to the OS. The data may still sit in a >> + * writeback cache of the host OS, but it will survive a crash of the qemu > Sorry, How to use the data in cache of host OS to survive acrash of the qemu? Just use the image file. Start a new qemu instance or whatever and you'll get the right data. Kevin