Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats

[Kevin Wolf <kwolf@redhat.com>]

Am 23.08.2017 um 19:44 hat John Snow geschrieben:
> On 08/23/2017 01:31 PM, Max Reitz wrote:
> > On 2017-08-22 21:07, John Snow wrote:
> > 
> > [...]
> > 
> >> (3) Add either a new flag that turns qcow2's backing file into a full
> >> R/W backing file, or add a new extension to qcow2 entirely (bypassing
> >> the traditional backing file mechanism to avoid confusion for older
> >> tooling) that adds a new read-write backing file field.
> >>
> >> This RW backing file field will be used for all reads AND writes; the
> >> qcow2 in question becomes a metadata container on top of the BDS chain.
> >> We can re-use Vladimir's bitmap persistence extension to save bitmaps in
> >> a qcow2 shell.
> >>
> >> The qcow2 becomes effectively a metadata cache for a new (essentially)
> >> filter node that handles features such as bitmaps. This could also be
> >> used to provide allocation map data for RAW files and other goodies down
> >> the road.
> >>
> >> Hopefully this achieves our desire to not create new formats AND our
> >> desire to concentrate features (and debugging, testing, etc) into qcow2,
> >> while allowing users to "have bitmaps with raw files."
> >>
> >> Of course, in this scenario, users now have two files: a qcow2 wrapper
> >> and the actual raw file in question; but regardless of how we were going
> >> to solve this, a raw file necessitates an external file of some sort,
> >> else we give up the idea that it was a raw file.
> >>
> >>
> >> Sound good?
> > 
> > While I don't quite like the idea of R/W backing files, I guess "don't
> > quite like" is still rather good.
> 
> Yeah, it's not necessarily my first pick, but it might be the least bad.

As for backing files always being read-only, that ship has sailed long
ago. We really never had it because I think HMP 'commit' was introduced
at the same time as backing files, but at least it was still contained
in synchronous function protected by the BQL. But at latest since we
introduced live block jobs, it's not a reasonable assumption to make any
more.

At this point, I have no problems with adding more users of writable
backing files any more. We'll have to use op blockers to make it safe.

> If you have any suggestions or alternatives for a way to accomplish the
> same in a way that does not leave any, even faint, bad taste in your
> mouth you are more than welcome to suggest it.

Maybe one thing that I don't want to dismiss right away would be a
separate BlockDriver for passthrough qcow2 images so that we don't
clutter all functions with special cases. But I'm not compeltely
convinced of it either.

I think I once had a use case for clusters that are marked as
"read/write to backing file", but I can't seem to remember it now. If we
had such a per-cluster setting, then a separate BlockDriver wouldn't be
an option, obviously.

Kevin