qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Eric Blake <eblake@redhat.com>
Cc: junyan.he@intel.com, qemu-devel@nongnu.org, kwolf@redhat.com,
	famz@redhat.com, quintela@redhat.com,
	crosthwaite.peter@gmail.com, dgilbert@redhat.com,
	mreitz@redhat.com, Pavel Dovgaluk <Pavel.Dovgaluk@ispras.ru>,
	pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH 02/10] RFC: Implement qcow2's snapshot dependent saving function.
Date: Mon, 14 May 2018 13:59:21 +0100	[thread overview]
Message-ID: <20180514125921.GA5182@stefanha-x1.localdomain> (raw)
In-Reply-To: <433eb0d1-c6b2-ff49-26b6-664636cfe5b0@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

On Tue, May 08, 2018 at 09:50:00AM -0500, Eric Blake wrote:
> On 03/13/2018 03:33 AM, junyan.he@intel.com wrote:
> > From: Junyan He <junyan.he@intel.com>
> > 
> > For qcow2 format, we can increase the cluster's reference count of
> > dependent snapshot content and link the offset to the L2 table of
> > the new snapshot point. This way can avoid obvious snapshot's dependent
> > relationship, so when we delete some snapshot point, just decrease the
> > cluster count and no need to check further.
> > 
> > Signed-off-by: Junyan He <junyan.he@intel.com>
> > ---
> >   block/qcow2-snapshot.c | 154 +++++++++++++++++++++++++++++++++++++++++++++++++
> >   block/qcow2.c          |   2 +
> >   block/qcow2.h          |   7 +++
> >   3 files changed, 163 insertions(+)
> 
> It sounds like you are trying to modify the qcow2 spec to store more
> information into the internal snapshot table (and if you aren't, why not? If
> an internal snapshot depends on another one and we don't record that
> information in the qcow2 metadata, then we are pushing the burden of
> tracking inter-relationships onto management apps, and risk corruption if
> you load a snapshot without also visiting its dependencies).  It is
> absolutely essential that such modifications be reflected in
> docs/interop/qcow2.txt first, to make sure we agree on the implementation.
> What's more, there is already another parallel proposal that is also wanting
> to tweak qcow2 files:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg05231.html
> 
> We need to make sure both additions are coordinated.

I think the relationship doesn't need to be stored.  The point of this
snapshot clone operation is to share some of the clusters of the parent
snapshot (using qcow2's existing cluster reference counts).  Cloning
avoids having to write a duplicate copy of those clusters.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2018-05-14 12:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13  8:33 [Qemu-devel] [PATCH 00/10] RFC: Optimize nvdimm kind memory for snapshot junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 01/10] RFC: Add save and support snapshot dependency function to block driver junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 02/10] RFC: Implement qcow2's snapshot dependent saving function junyan.he
2018-05-08 14:50   ` Eric Blake
2018-05-14 12:59     ` Stefan Hajnoczi [this message]
2018-03-13  8:33 ` [Qemu-devel] [PATCH 03/10] RFC: Implement save and support snapshot dependency in block driver layer junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 04/10] RFC: Set memory_region_set_log available for more client junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 05/10] RFC: Add memory region snapshot bitmap get function junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 06/10] RFC: Add save dependency functions to qemu_file junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 07/10] RFC: Add get_current_snapshot_info to get the snapshot state junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 08/10] RFC: Add a section_id parameter to save_live_iterate call junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 09/10] RFC: Add nvdimm snapshot saving to migration junyan.he
2018-03-13  8:33 ` [Qemu-devel] [PATCH 10/10] RFC: Enable nvdimm snapshot functions junyan.he
2018-03-15 13:55 ` [Qemu-devel] [PATCH 00/10] RFC: Optimize nvdimm kind memory for snapshot no-reply
2018-03-15 14:15 ` no-reply
2018-05-08  9:23 ` Stefan Hajnoczi
  -- strict thread matches above, loose matches on Subject: below --
2018-03-14  1:20 junyan.he
2018-03-14  1:20 ` [Qemu-devel] [PATCH 02/10] RFC: Implement qcow2's snapshot dependent saving function junyan.he

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=20180514125921.GA5182@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=Pavel.Dovgaluk@ispras.ru \
    --cc=crosthwaite.peter@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=junyan.he@intel.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    /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).