On Mon, Mar 14, 2011 at 2:49 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > On 03/14/2011 09:21 AM, Kevin Wolf wrote: >> >> 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). > > But is there any problem (in the format) with writing to the non-current > state? I can't think of one.
Here is a problem: there is a single global refcount table in QCOW2. You need to synchronize updates of the refcounts between multiple writers to avoid introducing incorrect refcounts. Stefan
