Re: [Qemu-devel] Closing Bitmaps (Was: Re: [PATCH v7 03/24] block: Release dirty bitmaps in bdrv_close())

[Fam Zheng <famz@redhat.com>]

On Tue, 11/17 12:05, John Snow wrote:
> Still the subject of debate on-list, but the thought is roughly this:

Thanks for summerizing this!

> 
> Bitmaps will be able to flush-to-file on close. (If they have no
> persistence data, it's a no-op (maybe.)) This might mean being flushed
> to their own BDS -- the one they are describing -- as a qcow2 extension.
> Or, it could be to an arbitrary new standalone file format designed for
> the sole purpose of containing bitmap data.
> 
> The discussion hasn't progressed beyond "Max and Kevin do not think
> storing arbitrary bitmaps in .qcow2 files is a good idea." The logical
> conclusion is "We need a new standalone format, then" but we haven't
> decided what that format will look like or how it will be used.

I second that. While storing dirty bitmap in the image itself sounds fine, it
is unlikely the best way for any other formats. Given that we will have a
standalone format for raw or other formats, it's probably not worth to extend
qcow2 specifically.

> 
> Then, Through CLI arguments or QMP arguments, you can modify the
> persistence attributes of bitmaps -- choosing where to store them.
> Bitmaps for qcow2 nodes can be stored in their own node, bitmaps
> describing raw files will need to be stored in an external file.
> 
> (Is it possible to create a block driver that doesn't implement
> read/write primitives, and only implements theoretical bitmap load/save
> primitives? We could create a block driver for a standalone bitmap
> container in this way...)

What about implementing it as a filter? It would work similar to blkdebug, with
.bdrv_co_writev to mark the in memory dirty bits (or even manage a
sophisticated cache to support large images efficiently), and .bdrv_close
to flush data to disk.

But that depends on the dynamic reconfigiration feature of block nodes, for
hot add/remove of dirty bitmap to work.

Fam