From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SelFm-0008S2-EV for qemu-devel@nongnu.org; Wed, 13 Jun 2012 06:56:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SelFe-0001oa-Gh for qemu-devel@nongnu.org; Wed, 13 Jun 2012 06:56:46 -0400 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:47870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SelFc-0001jy-SR for qemu-devel@nongnu.org; Wed, 13 Jun 2012 06:56:38 -0400 Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 13 Jun 2012 11:43:50 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q5DAn0CB49873098 for ; Wed, 13 Jun 2012 20:49:00 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q5DAuI4J012088 for ; Wed, 13 Jun 2012 20:56:19 +1000 Message-ID: <4FD871CF.7060703@linux.vnet.ibm.com> Date: Wed, 13 Jun 2012 16:26:15 +0530 From: Supriya Kannery MIME-Version: 1.0 References: <4FD0B759.8030002@redhat.com> <4FD1FBF1.10305@redhat.com> <4FD20D11.1080603@redhat.com> <4FD22422.1080301@redhat.com> <4FD23A73.8080502@redhat.com> <4FD5E97A.2010207@redhat.com> <4FD610B9.8070507@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support 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 , jcody@redhat.com, Zhi Hui Li , Taisuke Yamada , qemu-devel@nongnu.org On 06/12/2012 04:26 PM, Stefan Hajnoczi wrote: > On Mon, Jun 11, 2012 at 4:37 PM, Jeff Cody wrote: >> On 06/11/2012 10:24 AM, Stefan Hajnoczi wrote: >>> On Mon, Jun 11, 2012 at 1:50 PM, Kevin Wolf wrote: >>>> Am 11.06.2012 14:09, schrieb Stefan Hajnoczi: >>>>> On Fri, Jun 8, 2012 at 6:46 PM, Jeff Cody wrote: >>>>>> On 06/08/2012 12:11 PM, Kevin Wolf wrote: >>>>>>> Am 08.06.2012 16:32, schrieb Jeff Cody: >>>>>>>> On 06/08/2012 09:53 AM, Stefan Hajnoczi wrote: >>>>>>>>> On Fri, Jun 8, 2012 at 2:19 PM, Jeff Cody wrote: >>>>>>>>>> On 06/08/2012 08:42 AM, Stefan Hajnoczi wrote: >>>>>>>>>>> Let's figure out how to specify block-commit so we're all happy, that >>>>>>>>>>> way we can avoid duplicating work. Any comments on my notes above? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think we are almost completely on the same page - devil is in the >>>>>>>>>> details, of course (for instance, on how to convert the destination base >>>>>>>>>> from r/o to r/w). >>>>>>>>> >>>>>>>>> Great. The atomic r/o -> r/w transition and the commit coroutine can >>>>>>>>> be implemented on in parallel. Are you happy to implement the atomic >>>>>>>>> r/o -> r/w transition since you wrote bdrv_append()? Then Zhi Hui can >>>>>>>>> assume that part already works and focus on implementing the commit >>>>>>>>> coroutine in the meantime. I'm just suggesting a way to split up the >>>>>>>>> work, please let me know if you think this is good. >>>>>>>> >>>>>>>> I am happy to do it that way. I'll shift my focus to the atomic image >>>>>>>> reopen in r/w mode. I'll go ahead and post my diagrams and other info >>>>>>>> for block-commit on the wiki, because I don't think it conflicts with we >>>>>>>> discussed above (although I will modify my diagrams to not show commit >>>>>>>> from the top-level image). Of course, feel free to change it as >>>>>>>> necessary. >>>>>>> >>>>>>> I may have mentioned it before, but just in case: I think Supriya's >>>>>>> bdrv_reopen() patches are a good starting point. I don't know why they >>>>>>> were never completed, but I think we all agreed on the general design, >>>>>>> so it should be possible to pick that up. >>>>>>> >>>>>>> Though if you have already started with your own work on it, Jeff, I >>>>>>> expect that it won't be much different because it's basically the same >>>>>>> transactional approach that you know and that we already used for group >>>>>>> snapshots. >>>>>>> >>>>>> >>>>>> I will definitely use parts of Supriya's as it makes sense - what I >>>>>> started work on is similar to bdrv_append() and the current transaction >>>>>> approach, so there will be plenty in common to reuse, even with some >>>>>> differences. >>>>> >>>>> I have CCed Supriya who has been working on the reopen patch series. >>>>> She is close to posting a new version. >>>> >>>> It's just a bit disappointing that it takes several months between each >>>> two versions of the patch series. We'd like to have this in qemu 1.2, >>>> not only in qemu 1.14. >>>> >>>> I can understand if someone can't find the time, but then allow at least >>>> someone else to pick it up. >>> >>> Hey, don't shoot the messenger :). I just wanted add Supriya to CC so >>> she can join the discussion and see how much overlap there is with >>> what she's doing. We all contribute to QEMU from different angles and >>> with different priorities. If there is a time critical dependency on >>> the reopen code then discuss it here and the result will be that >>> someone officially drives the feature on. >>> >> >> I am more than happy to take the previous reopen() patches, and drive >> those forward, and also do whatever else is needed for live block >> commit. > > Supriya, > Can you share with us whether you have enough time to complete the > reopen() patches you've been working on? This functionality is a > dependency for the new block-commit command. Jeff is willing to take > on the reopen() work if you do not have time. Please let us know. > > Stefan > All, Sorry! for not following up these discussions and hence the delay in responding. After few month's gap, I had resumed working on bdrv_reopen() patchset but was not aware of this dependency and urgency. Will be posting whatever I have by tomorrow so that Jeff can use that code as needed for block-commit. - Supriya