From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52613 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pz8MC-0002IF-1S for qemu-devel@nongnu.org; Mon, 14 Mar 2011 10:02:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pz8M8-0006VF-Mg for qemu-devel@nongnu.org; Mon, 14 Mar 2011 10:02:46 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:65291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pz8M8-0006V3-IY for qemu-devel@nongnu.org; Mon, 14 Mar 2011 10:02:44 -0400 Received: by ywl41 with SMTP id 41so2544202ywl.4 for ; Mon, 14 Mar 2011 07:02:43 -0700 (PDT) Message-ID: <4D7E2001.8080201@codemonkey.ws> Date: Mon, 14 Mar 2011 09:02:41 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Strategic decision: COW format References: <4D5BC467.4070804@redhat.com> <4D5E4271.80501@redhat.com> <20110220221357.GO4580@hall.aurel32.net> <4D62295E.1030504@redhat.com> <4D7D036B.4050706@codemonkey.ws> <4D7E167A.1020509@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chunqiang Tang Cc: Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Aurelien Jarno , qemu-devel@nongnu.org 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. Regards, Anthony Liguori