qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Chunqiang Tang <ctang@us.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Markus Armbruster <armbru@redhat.com>,
	Aurelien Jarno <aurelien@aurel32.net>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Mon, 14 Mar 2011 08:22:02 -0500	[thread overview]
Message-ID: <4D7E167A.1020509@codemonkey.ws> (raw)
In-Reply-To: <OF1B5598FB.C373F3D7-ON85257853.000BAE11-85257853.000D6017@us.ibm.com>

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

  reply	other threads:[~2011-03-14 13:22 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF3C9DAE9F.EC6B5878-ON85257826.00715C10-85257826.007A14FB@LocalDomain>
2011-02-15 19:45 ` [Qemu-devel] Re: Comparing New Image Formats: FVD vs. QED Chunqiang Tang
2011-02-16 12:34   ` Kevin Wolf
2011-02-17 16:04     ` Chunqiang Tang
2011-02-18  9:12     ` Strategic decision: COW format (was: [Qemu-devel] Re: Comparing New Image Formats: FVD vs. QED) Markus Armbruster
2011-02-18  9:57       ` [Qemu-devel] Re: Strategic decision: COW format Kevin Wolf
2011-02-18 14:20         ` Anthony Liguori
2011-02-22  8:37           ` Markus Armbruster
2011-02-22  8:56             ` Kevin Wolf
2011-02-22 10:21               ` Markus Armbruster
2011-02-22 15:57               ` Anthony Liguori
2011-02-22 16:15                 ` Kevin Wolf
2011-02-22 18:18                   ` Anthony Liguori
2011-02-23  9:13                     ` Kevin Wolf
2011-02-23 14:21                       ` Anthony Liguori
2011-02-23 14:55                         ` Kevin Wolf
2011-02-23 13:43               ` Avi Kivity
2011-02-23 14:23                 ` Anthony Liguori
2011-02-23 14:38                   ` Kevin Wolf
2011-02-23 15:29                     ` Anthony Liguori
2011-02-23 15:36                       ` Avi Kivity
2011-02-23 15:47                         ` Anthony Liguori
2011-02-23 15:59                           ` Avi Kivity
2011-02-23 15:54                       ` Kevin Wolf
2011-02-23 15:23                   ` Avi Kivity
2011-02-23 15:31                     ` Anthony Liguori
2011-02-23 15:37                       ` Avi Kivity
2011-02-23 15:50                         ` Anthony Liguori
2011-02-23 16:03                           ` Avi Kivity
2011-02-23 16:04                             ` Anthony Liguori
2011-02-23 16:15                               ` Kevin Wolf
2011-02-25 11:20                             ` Pavel Dovgaluk
     [not found]                             ` <-1737654525499315352@unknownmsgid>
2011-02-25 13:22                               ` Stefan Hajnoczi
2011-02-23 15:52                         ` Anthony Liguori
2011-02-23 15:59                           ` Gleb Natapov
2011-02-23 16:00                           ` Avi Kivity
2011-02-23 15:33                     ` Daniel P. Berrange
2011-02-23 15:38                       ` Avi Kivity
2011-02-18 17:43         ` Stefan Weil
2011-02-18 19:11           ` Kevin Wolf
2011-02-18 19:47             ` Anthony Liguori
2011-02-18 20:49               ` Kevin Wolf
2011-02-18 20:50                 ` Anthony Liguori
2011-02-18 21:27                   ` Kevin Wolf
2011-02-19 17:19             ` Stefan Hajnoczi
2011-02-18 20:31           ` Anthony Liguori
2011-02-19 12:27           ` [Qemu-devel] Bugs in the VDI Block Device Driver Chunqiang Tang
2011-02-19 16:21             ` Stefan Hajnoczi
2011-02-19 18:49               ` Stefan Weil
2011-02-20 22:13         ` [Qemu-devel] Re: Strategic decision: COW format Aurelien Jarno
2011-02-21  8:59           ` Kevin Wolf
2011-02-21 13:44             ` Stefan Hajnoczi
2011-02-21 14:10               ` Kevin Wolf
2011-02-21 15:16                 ` Anthony Liguori
2011-02-21 15:26                   ` Kevin Wolf
2011-02-23  3:32               ` Chunqiang Tang
2011-02-23 13:20                 ` Markus Armbruster
     [not found]               ` <OFAEB4CD91.BE989F29-ON8525783F.007366B8-85257840.00130B47@LocalDomain>
2011-03-13  5:51                 ` Chunqiang Tang
2011-03-13 17:48                   ` Anthony Liguori
2011-03-14  2:28                     ` Chunqiang Tang
2011-03-14 13:22                       ` Anthony Liguori [this message]
2011-03-14 13:53                         ` Chunqiang Tang
2011-03-14 14:02                           ` Anthony Liguori
2011-03-14 14:21                             ` Kevin Wolf
2011-03-14 14:35                               ` Chunqiang Tang
2011-03-14 14:49                               ` Anthony Liguori
2011-03-14 15:05                                 ` Stefan Hajnoczi
2011-03-14 15:08                                 ` Kevin Wolf
2011-03-14 14:26                           ` Stefan Hajnoczi
2011-03-14 14:30                             ` Chunqiang Tang
2011-03-14 14:15                         ` Kevin Wolf
2011-03-14 14:25                           ` Chunqiang Tang
2011-03-14 14:31                             ` Stefan Hajnoczi
2011-03-14 16:32                               ` Chunqiang Tang
2011-03-14 17:57                                 ` Kevin Wolf
2011-03-14 19:23                                   ` Chunqiang Tang
2011-03-14 20:16                                     ` Kevin Wolf
     [not found]                               ` <OF7C2FDD40.E76A4E14-ON85257853.005ADD68-85257853.005AF16E@LocalDomain>
2011-03-14 21:32                                 ` Chunqiang Tang
2011-03-14 14:34                             ` Kevin Wolf
2011-03-14 14:47                           ` Anthony Liguori
2011-03-14 15:03                             ` Kevin Wolf
2011-03-14 15:13                               ` Anthony Liguori
2011-03-14 15:04                             ` Chunqiang Tang
2011-03-14 15:07                               ` Stefan Hajnoczi
2011-03-14 10:12                   ` Kevin Wolf
2011-02-22  8:40           ` Markus Armbruster
2011-02-16 13:21   ` [Qemu-devel] Re: Comparing New Image Formats: FVD vs. QED Stefan Hajnoczi
2011-02-17 16:04     ` Chunqiang Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D7E167A.1020509@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=aurelien@aurel32.net \
    --cc=ctang@us.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).