From: Max Reitz <mreitz@redhat.com>
To: "Patrik Janoušek" <pj@patrikjanousek.cz>,
"Kevin Wolf" <kwolf@redhat.com>, "Eric Blake" <eblake@redhat.com>,
"Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
"John Snow" <jsnow@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: Fwd: [PATCH 0/2] block/raw: implemented persistent dirty bitmap and ability to dump bitmap content via qapi
Date: Mon, 22 Mar 2021 11:48:08 +0100 [thread overview]
Message-ID: <6e142c5b-053c-dc58-277c-59a8ce67f8a7@redhat.com> (raw)
In-Reply-To: <856ca6ba-3871-068f-f821-269c40a5a4d5@patrikjanousek.cz>
Hi,
On 20.03.21 11:01, Patrik Janoušek wrote:
> I'm sorry, but I forgot to add you to the cc, so I'm forwarding the
> patch to you additionally. I don't want to spam the mailing list
> unnecessarily.
I think it’s better to still CC the list. It’s so full of mail, one
more won’t hurt. :)
(Re-adding qemu-block and qemu-devel, because the discussion belongs on
the list(s).)
> -------- Forwarded Message --------
> Subject: [PATCH 0/2] block/raw: implemented persistent dirty bitmap and
> ability to dump bitmap content via qapi
> Date: Sat, 20 Mar 2021 10:32:33 +0100
> From: Patrik Janoušek <pj@patrikjanousek.cz>
> To: qemu-devel@nongnu.org
> CC: Patrik Janoušek <pj@patrikjanousek.cz>, lmatejka@kiv.zcu.cz
>
>
>
> Currently, QEMU doesn't support persistent dirty bitmaps for raw format
> and also dirty bitmaps are for internal use only, and cannot be accessed
> using third-party applications. These facts are very limiting
> in case someone would like to develop their own backup tool becaouse
> without access to the dirty bitmap it would be possible to implement
> only full backups. And without persistent dirty bitmaps, it wouldn't
> be possible to keep track of changed data after QEMU is restarted. And
> this is exactly what I do as a part of my bachelor thesis. I've
> developed a tool that is able to create incremental backups of drives
> in raw format that are LVM volumes (ability to create snapshot is
> required).
Similarly to what Vladimir has said already, the thing is that
conceptually I can see no difference between having a raw image with the
bitmaps stored in some other file, i.e.:
{ "driver": "raw",
"dirty-bitmaps": [ {
"filename": "sdc1.bitmap",
"persistent": true
} ],
"file": {
"driver": "file",
"filename": "/dev/sdc1"
} }
And having a qcow2 image with the raw data stored in some other file, i.e.:
{ "driver": "qcow2",
"file": {
"driver": "file",
"filename": "sdc1.metadata"
},
"data-file": {
"driver": "file",
"filename": "/dev/sdc1"
} }
(Where sdc1.metadata is a qcow2 file created with
“data-file=/dev/sdc1,data-file-raw=on”.)
To use persistent bitmaps with raw images, you need to add metadata
(namely, the bitmaps). Why not store that metadata in a qcow2 file?
Max
next prev parent reply other threads:[~2021-03-22 10:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-20 9:32 [PATCH 0/2] block/raw: implemented persistent dirty bitmap and ability to dump bitmap content via qapi Patrik Janoušek
2021-03-20 9:32 ` [PATCH 1/2] block/raw: added support of persistent dirty bitmaps Patrik Janoušek
2021-03-22 8:41 ` Vladimir Sementsov-Ogievskiy
2021-03-22 10:18 ` Patrik Janoušek
2021-03-22 10:46 ` Vladimir Sementsov-Ogievskiy
2021-03-22 11:18 ` Vladimir Sementsov-Ogievskiy
2021-03-22 11:36 ` Patrik Janoušek
2021-03-22 20:27 ` Lubos Matejka
2021-03-22 15:43 ` Kevin Wolf
2021-03-20 9:32 ` [PATCH 2/2] qapi: implementation of the block-dirty-bitmap-dump command Patrik Janoušek
2021-03-22 9:02 ` Vladimir Sementsov-Ogievskiy
2021-03-22 15:12 ` Kevin Wolf
2021-03-22 8:29 ` [PATCH 0/2] block/raw: implemented persistent dirty bitmap and ability to dump bitmap content via qapi Vladimir Sementsov-Ogievskiy
2021-03-22 8:57 ` Patrik Janoušek
2021-03-22 14:53 ` Kevin Wolf
[not found] ` <856ca6ba-3871-068f-f821-269c40a5a4d5@patrikjanousek.cz>
2021-03-22 10:48 ` Max Reitz [this message]
2021-03-22 11:27 ` Fwd: " Patrik Janoušek
2021-03-22 12:06 ` Max Reitz
2021-03-22 21:45 ` Patrik Janoušek
2021-03-22 12:44 ` Fabian Grünbichler
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=6e142c5b-053c-dc58-277c-59a8ce67f8a7@redhat.com \
--to=mreitz@redhat.com \
--cc=eblake@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=pj@patrikjanousek.cz \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).