From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33111 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ov944-0001m0-WB for qemu-devel@nongnu.org; Mon, 13 Sep 2010 09:27:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ov943-0002ab-Qy for qemu-devel@nongnu.org; Mon, 13 Sep 2010 09:27:20 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:45776) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ov943-0002aK-LX for qemu-devel@nongnu.org; Mon, 13 Sep 2010 09:27:19 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o8DDGr4e029094 for ; Mon, 13 Sep 2010 07:16:53 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o8DDRGQg163066 for ; Mon, 13 Sep 2010 07:27:16 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o8DDRFOE022923 for ; Mon, 13 Sep 2010 07:27:16 -0600 Message-ID: <4C8E26B3.3060302@linux.vnet.ibm.com> Date: Mon, 13 Sep 2010 08:27:15 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1284213896-12705-1-git-send-email-aliguori@us.ibm.com> <1284213896-12705-2-git-send-email-aliguori@us.ibm.com> <4C8DDF18.5030703@redhat.com> In-Reply-To: <4C8DDF18.5030703@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/3] block: allow migration to work with image files List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Anthony Liguori , Juan Quintela , qemu-devel@nongnu.org, Stefan Hajnoczi On 09/13/2010 03:21 AM, Kevin Wolf wrote: > Am 11.09.2010 16:04, schrieb Anthony Liguori: > >> Image files have two types of data: immutable data that describes things like >> image size, backing files, etc. and mutable data that includes offset and >> reference count tables. >> >> Today, image formats aggressively cache mutable data to improve performance. In >> some cases, this happens before a guest even starts. When dealing with live >> migration, since a file is open on two machines, the caching of meta data can >> lead to data corruption. >> >> This patch addresses this by introducing a mechanism to invalidate any cached >> mutable data a block driver may have which is then used by the live migration >> code. >> >> NB, this still requires coherent shared storage. Addressing migration without >> coherent shared storage (i.e. NFS) requires additional work. >> >> Signed-off-by: Anthony Liguori >> >> diff --git a/block.c b/block.c >> index ebbc376..cd2ee31 100644 >> --- a/block.c >> +++ b/block.c >> @@ -1453,6 +1453,22 @@ const char *bdrv_get_device_name(BlockDriverState *bs) >> return bs->device_name; >> } >> >> +void bdrv_invalidate_cache(BlockDriverState *bs) >> +{ >> + if (bs->drv&& bs->drv->bdrv_invalidate_cache) { >> + bs->drv->bdrv_invalidate_cache(bs); >> + } >> +} >> > There is a simple generic implementation: > > drv = bs->drv; > drv->close(bs); > drv->open(bs, bs->open_flags); > > Note that this only reopens e.g. the qcow2 layer, but not the image > file, which is bs->file. > That's a pretty good idea for a general implementation, I'll update the patches accordingly. Regards, Anthony Liguori > This works for all simple case, that is, one format on top of one or > more protocols, where the protocols don't need invalidation. I think > this includes everything that is possible today. With -blockdev we might > need to revise this to include the lower layers, too. (But only > sometimes, because we don't want to reopen the file) > > Kevin >