qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kashyap Chamarthy <kchamart@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Bharadwaj Rayala <bharadwaj.rayala@rubrik.com>,
	qemu-devel@nongnu.org, Kashyap Chamarthy <kashyap.cv@gmail.com>,
	Suman Swaroop <suman.swaroop@rubrik.com>,
	John Snow <jsnow@redhat.com>,
	qemu-discuss@nongnu.org
Subject: Re: [Qemu-devel] Incremental drive-backup with dirty bitmaps
Date: Thu, 24 Jan 2019 10:16:49 +0100	[thread overview]
Message-ID: <20190124091649.GF23279@paraplu> (raw)
In-Reply-To: <9aef3157-e49e-4b53-f0de-75593df06da9@redhat.com>

On Wed, Jan 23, 2019 at 01:09:41PM -0600, Eric Blake wrote:
> On 1/23/19 12:08 PM, Bharadwaj Rayala wrote:

[...] # [Snip Eric's excellent exposition.]

> > What do you mean by issues? Do you mean any data/corruption bugs or lack of
> > some nice functionality that we are talking here?
> 
> Lack of functionality.  In particular, the 4.0 commands
> block-dirty-bitmap-{enable,merge,disable} (or their 3.1 counterparts
> x-block-dirty-bitmap-*) are essential to the workflow of differential
> backups (without being able to manage bitmaps yourself, you can only get
> the weaker incremental backup, and that means qemu itself is clearing
> the bitmap out of under your feet on success, and where you are having
> to worry about completion-mode=grouped).
> 
> > 
> > Thanks a lot Eric for spending your time in answering my queries. I dont
> > know if you work with Kashyap Chamarthy, but your help and his blogs are
> > lifesavers.
> 
> Yes, Kashyap is trying to build solutions on top of the building blocks
> that I am working on, so we have collaborated several times on these
> types of issues (he does a lot better at blog posts extracted from my
> mailing list brain dumps).

I haven't kept up with incremental backups lately, as I've been swamped
with other work.  But two other documents that I can point to are these
[1][2] in the QEMU tree.  And their HTML-rendered versions are
here[3][4].  They're generated for 3.0.0; but these docs haven't changed
much since then.

Along with Eric's last year talk, also check out presentations from
previous KVM Forums from other Block Layer maintainers.


[1] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/live-block-operations.rst
[2] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/bitmaps.rst
[3] https://kashyapc.fedorapeople.org/QEMU-Docs-v3.0.0/_build/html/docs/interop/live-block-operations.html
[4] https://kashyapc.fedorapeople.org/QEMU-Docs-v3.0.0/_build/html/docs/interop/bitmaps.html


-- 
/kashyap

  reply	other threads:[~2019-01-24  9:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 19:29 [Qemu-devel] Incremental drive-backup with dirty bitmaps Bharadwaj Rayala
2019-01-22 21:54 ` Eric Blake
2019-01-23 18:08   ` Bharadwaj Rayala
2019-01-23 19:09     ` Eric Blake
2019-01-24  9:16       ` Kashyap Chamarthy [this message]
     [not found]         ` <CAMAMwPA_H77fnC+dOzBt+nRQ+=oPHtpw2DRYMCEtnGdo1OU0Hw@mail.gmail.com>
2019-02-06 17:20           ` Suman Swaroop
2019-02-06 17:57             ` Eric Blake
2019-01-24  8:57 ` Kashyap Chamarthy

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=20190124091649.GF23279@paraplu \
    --to=kchamart@redhat.com \
    --cc=bharadwaj.rayala@rubrik.com \
    --cc=eblake@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kashyap.cv@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@nongnu.org \
    --cc=suman.swaroop@rubrik.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).