Re: [PATCH 0/2] block/raw: implemented persistent dirty bitmap and ability to dump bitmap content via qapi

[Kevin Wolf <kwolf@redhat.com>]

Hi Patrik,

Am 22.03.2021 um 09:57 hat Patrik Janoušek geschrieben:
> On 3/22/21 9:29 AM, Vladimir Sementsov-Ogievskiy wrote:
> > We do have external incremental backups, based on Qemu bitmap API. But
> > it depends of course on qcow2 persistent bitmaps feature.
>
> Yes, I know. And that's the problem. The point of my bachelor thesis is
> to implement a backup solution for the raw format.

the problem with this is that raw isn't really a format, it's more the
absence of a format. You just have the content of the virtual disk in a
file and that's it. This means not having any metadata (apart from the
metadata stored in the filesystem, of course).

As soon as you add metadata in some way (in your case, by referencing
additional metadata files in runtime options), it's not raw any more. If
you write to the raw image file without updating the metadata, the
metadata becomes inconsistent with the content. In other words, both
files form a single disk image together and can only be used together or
you're breaking them.

This in turn means that you have just invented a new image format. It's
a bit unconventional in that it's spread across multiple files, and that
some of the metadata that brings everything together is even in command
line options instead of a file, but you have to combine these components
in the same way every time you start the VM, so it really is a new image
format.

We have gone through such discussions a while ago because obviously "raw
with dirty bitmaps" was a request that came soon after we discussed
persistent dirty maps. But as we came to the conclusion that any
addition to raw would create another new image format specific to QEMU,
we decided that we can as well use qcow2 for this, which is already the
fully featured QEMU image format.

I hope this background helps a bit to explain the reactions you have
received so far.

Kevin