[Top][All Lists]

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

Re: [Qemu-devel] Re: Strategic decision: COW format

From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Mon, 14 Mar 2011 15:21:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

Am 14.03.2011 15:02, schrieb Anthony Liguori:
> On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
>>> No, because the copy-on-write is another layer on top of the snapshot
>>> and AFAICT, they don't persist when moving between snapshots.
>>> The equivalent for external snapshots would be:
>>> base0<- base1<- base2<- image
>>> And then if I wanted to move to base1 without destroying base2 and
>>> image, I could do:
>>> qemu-img create -f qcow2 -b base1 base1-overlay.img
>>> The file system can keep a lot of these things around pretty easily but
>>> with your proposal, it seems like there can only be one.  If you support
>>> many of them, I think you'll degenerate to something as complex as a
>>> reference count table.
>>> On the other hand, I think it's reasonable to just avoid the CoW overlay
>>> entirely and say that moving to a previous snapshot destroys any of it's
>>> children.  I think this ends up being a simplifying assumption that is
>>> worth investigating further.
>> No, both VMware and FVD have the same semantics as QCOW2. Moving to a
>> previous snapshot does not destroy any of its children. In the example I
>> gave (copied below),
>> it goes from
>> Image: s1->s2->s3->s4->(current-state)
>> back to snapshot s2, and now the state is
>> Image: s1->s2->s3->s4
>>             |->(curren-state)
>> where all snapshots s1-s4 are kept. From there, it can take another
>> snapshot s5, and then further go back to snapshot s4, ending up with
>> Image: s1->s2->s3->s4
>>             |->s5   |
>>                     |->  (current-state)
> Your use of "current-state" is confusing me because AFAICT, 
> current-state is just semantically another snapshot.
> It's writable because it has no children.  You only keep around one 
> writable snapshot and to make another snapshot writable, you have to 
> discard the former.
> This is not the semantics of qcow2.  Every time you create a snapshot, 
> it's essentially a new image.  You can write directly to it.
> While we don't do this today and I don't think we ever should, it's 
> entirely possible to have two disks served simultaneously out of the 
> same qcow2 file using snapshots.

No, CQ is describing the semantics of internal snapshots in qcow2
correctly. You have all the snapshots that are stored in the snapshot
table (all read-only) plus one current state described by the image
header (read-write).


reply via email to

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