On 06/10/2015 02:19 AM, Vladimir Sementsov-Ogievskiy wrote: >>> +Dirty bitmaps is an optional header extension. It provides a >>> possibility of >>> +storing dirty bitmaps in qcow2 image. The fields are: >>> + >>> + 0 - 3: nb_dirty_bitmaps >>> + Number of dirty bitmaps contained in the image >> Is there a maximum? > hmm. any proposals for this? >> >>> + >>> + 4 - 11: dirty_bitmaps_offset
I'm not sure if there is a reasonable cap on the number of dirty bitmaps; I doubt that anyone will actually supply all 4G possible images allowed by the four-byte field, but don't have a suggestion on a smaller limit that doesn't feel arbitrary. [meta-comment] It's very hard to pick out the new content in your reply if you do not separate your new text with a newline both before and after (as I'm doing here). >>> +Dirty bitmaps are stored using a ONE-level structure for the mapping of >>> +bitmaps to host clusters. There is only an L1 table. >>> + >>> +The L1 table has a variable size (stored in the Bitmap table entry) >>> and may >>> +use multiple clusters, however it must be contiguous in the image file. >> The use of "L1 table" could be confusing. The refcount metadata uses >> "refcount table" and "refcount block" to describe a one-level table. > I agree. Hmm.. dirty bitmaps table? ok? "dirty bitmaps table" works for me, as a name for the one-level table. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
