[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-devel
Subject:    Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
From:       Stefan Hajnoczi <stefanha () gmail ! com>
Date:       2012-06-12 10:56:47
Message-ID: CAJSP0QUj8chwJmbPiwS_52vJ35ikBMH_5TarENGODH7XP3_aSg () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jun 11, 2012 at 4:37 PM, Jeff Cody <jcody@redhat.com> wrote:
> On 06/11/2012 10:24 AM, Stefan Hajnoczi wrote:
>> On Mon, Jun 11, 2012 at 1:50 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>>> Am 11.06.2012 14:09, schrieb Stefan Hajnoczi:
>>>> On Fri, Jun 8, 2012 at 6:46 PM, Jeff Cody <jcody@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 <jcody@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. =A0Any comments on my notes a=
bove?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think we are almost completely on the same page - devil is in t=
he
>>>>>>>>> details, of course (for instance, on how to convert the destinati=
on base
>>>>>>>>> from r/o to r/w).
>>>>>>>>
>>>>>>>> Great. =A0The atomic r/o -> r/w transition and the commit coroutin=
e can
>>>>>>>> be implemented on in parallel. =A0Are you happy to implement the a=
tomic
>>>>>>>> r/o -> r/w transition since you wrote bdrv_append()? =A0Then Zhi H=
ui can
>>>>>>>> assume that part already works and focus on implementing the commi=
t
>>>>>>>> coroutine in the meantime. =A0I'm just suggesting a way to split u=
p the
>>>>>>>> work, please let me know if you think this is good.
>>>>>>>
>>>>>>> I am happy to do it that way. =A0I'll shift my focus to the atomic =
image
>>>>>>> reopen in r/w mode. =A0I'll go ahead and post my diagrams and other=
 info
>>>>>>> for block-commit on the wiki, because I don't think it conflicts wi=
th we
>>>>>>> discussed above (although I will modify my diagrams to not show com=
mit
>>>>>>> from the top-level image). =A0Of 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 th=
ey
>>>>>> were never completed, but I think we all agreed on the general desig=
n,
>>>>>> 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 sa=
me
>>>>>> transactional approach that you know and that we already used for gr=
oup
>>>>>> 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 transacti=
on
>>>>> 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 leas=
t
>>> someone else to pick it up.
>>
>> Hey, don't shoot the messenger :). =A0I just wanted add Supriya to CC so
>> she can join the discussion and see how much overlap there is with
>> what she's doing. =A0We all contribute to QEMU from different angles and
>> with different priorities. =A0If 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

[prev in list] [next in list] [prev in thread] [next in thread]