qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
Date: Mon, 11 Jun 2012 14:50:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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.

Kevin



reply via email to

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