From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfB36-0000nd-3r for qemu-devel@nongnu.org; Thu, 14 Jun 2012 10:29:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfB2z-0002eu-Hm for qemu-devel@nongnu.org; Thu, 14 Jun 2012 10:29:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfB2z-0002eT-9I for qemu-devel@nongnu.org; Thu, 14 Jun 2012 10:29:17 -0400 Message-ID: <4FD9F52E.3050507@redhat.com> Date: Thu, 14 Jun 2012 10:29:02 -0400 From: Jeff Cody 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> <4FD9F3E8.8080306@linux.vnet.ibm.com> In-Reply-To: <4FD9F3E8.8080306@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support Reply-To: jcody@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Hui Li Cc: Kevin Wolf , Supriya Kannery , zhihuili@cn.ibm.com, Taisuke Yamada , Stefan Hajnoczi , qemu-devel@nongnu.org On 06/14/2012 10:23 AM, Zhi Hui Li wrote: > On 2012=E5=B9=B406=E6=9C=8811=E6=97=A5 23:37, 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 wr= ote: >>>>>>>>>> On 06/08/2012 08:42 AM, Stefan Hajnoczi wrote: >>>>>>>>>>> Let's figure out how to specify block-commit so we're all hap= py, 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 i= n the >>>>>>>>>> details, of course (for instance, on how to convert the destin= ation base >>>>>>>>>> from r/o to r/w). >>>>>>>>> >>>>>>>>> Great. The atomic r/o -> r/w transition and the commit corout= ine 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 co= mmit >>>>>>>>> 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 othe= r 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 de= sign, >>>>>>> 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 transa= ction >>>>>> approach, so there will be plenty in common to reuse, even with so= me >>>>>> 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 e= ach >>>> 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 l= east >>>> someone else to pick it up. >>> >>> Hey, don't shoot the messenger :). I just wanted add Supriya to CC s= o >>> 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 an= d >>> 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. >> >> It sounds like Zhi Hui is working on live block commit patches, and >> Supriya is working on the bdrv_reopen() portion - I don't want to >> duplicate any effort, but if there is anything I can do to help with >> either of those areas, just let me know. >> >> Thanks, >> Jeff >> >> >> > Jeff please go ahead with block-commit, I > am finishing up my fdc async conversion patch series first. I will > reply when I'm ready to work on block-commit. >=20 > Thank you very much! >=20 Hi Zhi, I will do that. Thanks! Jeff