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