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
next prev parent 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).