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.