On 11/17/2015 09:29 PM, Fam Zheng wrote: > 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. >
We do already have the code, though, and for simple desktop use cases it's very, very convenient, though it does leave us with two usage cases for bitmaps. I believe Denis and Vladimir plan to allow for Parallels to support the inline bitmap load/store primitive, too. I think the model of "Store in the image if you can, use an external otherwise" is perfectly fine -- if not slightly more complicated than what the bare minimum feature requires. I think the usability boost it provides to users is worth the maintenance and review burden. For now, I think Vladimir is working on the qcow2 extension first, and we'll visit the generic file format later. Is it possible to create a block driver that *only* supports the bitmap load/store primitives? (I.e. -- no read/write support at all?) >> >> 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 > Filters I think would be the ideal path, but if the QMP and CLI features around dynamic reconfiguration are not quite ready, that route may not be open to us... or not in a timely fashion, anyway.
