On Mon, Jun 11, 2012 at 4:37 PM, Jeff Cody <jc...@redhat.com> wrote: > On 06/11/2012 10:24 AM, Stefan Hajnoczi wrote: >> On Mon, Jun 11, 2012 at 1:50 PM, Kevin Wolf <kw...@redhat.com> wrote: >>> Am 11.06.2012 14:09, schrieb Stefan Hajnoczi: >>>> On Fri, Jun 8, 2012 at 6:46 PM, Jeff Cody <jc...@redhat.com> 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 <jc...@redhat.com> 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
