All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: "Denis V. Lunev" <den@openvz.org>,
	Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] RFC: incremental backups: qmp-block-dirty-bitmap-diff
Date: Mon, 22 Feb 2016 17:48:20 -0500	[thread overview]
Message-ID: <56CB9034.5050402@redhat.com> (raw)
In-Reply-To: <20160214080232.GE31933@ad.usersys.redhat.com>



On 02/14/2016 03:02 AM, Fam Zheng wrote:
> On Tue, 02/09 19:48, John Snow wrote:
>> - Reading an entire drive to populate a bitmap with the understanding
>> that an incremental backup is soon to follow is inefficient if the drive
>> is more than just a little dirty: it may have been quicker to just
>> create a new full backup and bitmap.
> 
> Above all I think this is a good idea. Just as an alternative, can we add
> another sync mode for drive-backup?
> 
>     (QMP) drive-backup device=d0 target=target.qcow2 format=qcow2 sync=diff \
>                        base=full-backup.qcow2
> 
> (the data of d0 will be compared against full-backup.qcow2 and only different
> clusters will be copied to target.qcow2)
> 
> Fam
> 

I like this idea too, since it has the chance to do a lot of things for
us all at once. If we allow a user to pass a bitmap that we can
synchronize to this backup, it will be one command that can do a few
things all at once.

Using the "bitmap-diff" approach [re-]establishes a bitmap, but still
requires you to make the next backup. sync=diff just combines the two
logical steps into one.


There are two phases here:
[Perform the diff] [Create a backup from that diff]


backup mode=diff as suggested above performs both,
block-dirty-bitmap-diff as suggested previously performs just the first
action, while we already have commands to perform the second.

I think arguably we'd only /need/ the bitmap-diff command, but I
wouldn't personally mind having both for flexibility reasons (which
historically don't fly too far on the qemu mailing list...)


I think I will move ahead with prototyping the QMP command and see how
far I get. If it's not too bad I'll send some code out for further debate.

--js

      reply	other threads:[~2016-02-22 22:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-10  0:48 [Qemu-devel] RFC: incremental backups: qmp-block-dirty-bitmap-diff John Snow
2016-02-14  8:02 ` Fam Zheng
2016-02-22 22:48   ` John Snow [this message]

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=56CB9034.5050402@redhat.com \
    --to=jsnow@redhat.com \
    --cc=den@openvz.org \
    --cc=famz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@parallels.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 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.