From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RT3tZ-0004V5-14 for qemu-devel@nongnu.org; Tue, 22 Nov 2011 22:53:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RT3tX-00085g-Tz for qemu-devel@nongnu.org; Tue, 22 Nov 2011 22:53:13 -0500 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:46806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RT3tX-00085L-03 for qemu-devel@nongnu.org; Tue, 22 Nov 2011 22:53:11 -0500 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 Nov 2011 09:23:06 +0530 Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAN3r0CP3731696 for ; Wed, 23 Nov 2011 09:23:00 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAN3qxJO017251 for ; Wed, 23 Nov 2011 14:52:59 +1100 Message-ID: <4ECC6E1A.9050501@linux.vnet.ibm.com> Date: Wed, 23 Nov 2011 09:22:58 +0530 From: Supriya Kannery MIME-Version: 1.0 References: <20111111064707.15024.69847.sendpatchset@skannery.in.ibm.com> <20111111064818.15024.2323.sendpatchset@skannery.in.ibm.com> <4ECA407A.6030507@in.ibm.com> <4ECB7866.50405@in.ibm.com> <4ECB81A5.60600@redhat.com> <4ECB84A1.8000700@in.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [v9 Patch 5/6]Qemu: Framework for reopening images safely Reply-To: supriyak@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , qemu-devel@nongnu.org, Luiz Capitulino , Christoph Hellwig , supriya kannery On 11/22/2011 05:19 PM, Stefan Hajnoczi wrote: > On Tue, Nov 22, 2011 at 11:16 AM, supriya kannery wrote: >> Kevin Wolf wrote: >>> >>> Am 22.11.2011 11:24, schrieb supriya kannery: >>> >>>> >>>>> >>>>> How does VMDK implement its prepare/commit/abort? It needs to use the >>>>> "public" bdrv_reopen_prepare() function on its image files. >>>>> >>>> >>>> bdrv_reopen() is the public interface which gets called by any of the >>>> image formats. >>>> So VMDK or any image format has to call bdrv_reopen which decides to call >>>> driver specific prepare/commit/abort or simply close and reopen the file. >>>> >>> >>> No, that doesn't work. In order to get all-or-nothing semantics, you >>> need to explicitly prepare all child images and only when you know the >>> results of all preparations, you can decide whether to commit or abort >>> all. >>> >> >> bdrv_reopen_prepare/commit/abort will be implemented specific to VMDK in >> vmdk.c. Then for vmdk, >> drv->bdrv_reopen_prepare() will handle preparing child images and return >> success to bdrv_reopen () >> only if all of them get prepared successfully. The prepare/commit/abort >> concept we took up considering >> vmdk's special case of multiple files. >> >> So it is bdrv_reopen() which is public and called by hostcache change >> request for any of the image formats. >> It then routes the processing to respective prepare/commit/abort implemented >> by the drivers, including VMDK. >> In cases where drivers don't have their own implementation, default route is >> taken which is simply >> closing and opening the file. > > VMDK must call bdrv_reopen_prepare()/bdrv_reopen_commit()/bdrv_reopen_abort() > on its child images in order to support aborting when there is a > failure half-way through. If it used bdrv_reopen() on its child > images then it could not roll back later when there is a failure on > the next child. > I got both your's and Kevin's point now, after looking into vmdk.c code related to extents. My initial understanding was bdrv_reopen_prepare() implemented inside vmdk.c can be called for handling reopening of multiple child images. But observing how vmdk_open() is implemented for child images, I should follow that method. So will make bdrv_reopen_prepare()/commit/abort in block.c to be used by vmdk as well as other required image formats (like how raw.c is using them). - thanks, Supriya