All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: junyan.he@intel.com, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, famz@redhat.com, crosthwaite.peter@gmail.com,
	quintela@redhat.com, dgilbert@redhat.com, mreitz@redhat.com,
	pbonzini@redhat.com, rth@twiddle.net,
	Pavel Dovgaluk <Pavel.Dovgaluk@ispras.ru>
Subject: Re: [Qemu-devel] [PATCH 02/10] RFC: Implement qcow2's snapshot dependent saving function.
Date: Tue, 8 May 2018 09:50:00 -0500	[thread overview]
Message-ID: <433eb0d1-c6b2-ff49-26b6-664636cfe5b0@redhat.com> (raw)
In-Reply-To: <1520930033-18885-3-git-send-email-junyan.he@intel.com>

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.


> +
> +    if (!QEMU_IS_ALIGNED(depend_offset,  s->cluster_size)) {

Why two spaces here and elsewhere?


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

  reply	other threads:[~2018-05-08 14:50 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 [this message]
2018-05-14 12:59     ` Stefan Hajnoczi
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
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=433eb0d1-c6b2-ff49-26b6-664636cfe5b0@redhat.com \
    --to=eblake@redhat.com \
    --cc=Pavel.Dovgaluk@ispras.ru \
    --cc=crosthwaite.peter@gmail.com \
    --cc=dgilbert@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.