qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).