From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56628 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pz7ip-0003ib-RD for qemu-devel@nongnu.org; Mon, 14 Mar 2011 09:22:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pz7io-0006QJ-Ih for qemu-devel@nongnu.org; Mon, 14 Mar 2011 09:22:07 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:57915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pz7io-0006Q6-Aw for qemu-devel@nongnu.org; Mon, 14 Mar 2011 09:22:06 -0400 Received: by gwb19 with SMTP id 19so2243837gwb.4 for ; Mon, 14 Mar 2011 06:22:05 -0700 (PDT) Message-ID: <4D7E167A.1020509@codemonkey.ws> Date: Mon, 14 Mar 2011 08:22:02 -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> 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/13/2011 09:28 PM, Chunqiang Tang wrote: >>> In short, FVD's internal snapshot achieves the ideal properties of > G1-G6, >>> by 1) using the reference count table to only track "static" > snapshots, 2) >>> not keeping the reference count table in memory, 3) not updating the >>> on-disk "static" reference count table when the VM runs, and 4) >>> efficiently tracking dynamically allocated blocks by piggybacking on > FVD's >>> other features, i.e., its journal and small one-level lookup table. >> Are you assuming snapshots are read-only? >> >> It's not clear to me how this would work with writeable snapshots. It's >> not clear to me that writeable snapshots are really that important, but >> this is an advantage of having a refcount table. >> >> External snapshots are essentially read-only snapshots so I can >> understand the argument for it. > By definition, a snapshot itself must be immutable (read-only), but a > writeable > image state can be derived from an immutable snapshot by using > copy-on-write, > which I guess is what you meant by "writeable snapshot." 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. From the use-cases that I'm aware of (backup and RAS), I think these semantics are okay. I'm curious what other people think (Kevin/Stefan?). Regards, Anthony Liguori