[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support

From: Jeff Cody
Subject: Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
Date: Mon, 11 Jun 2012 11:37:29 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]