Am 14.12.2015 um 21:05 hat Max Reitz geschrieben:
On 14.12.2015 18:43, Vladimir Sementsov-Ogievskiy wrote:
The new feature for qcow2: storing dirty bitmaps.
Only dirty bitmaps relative to this qcow2 image should be stored in it.
Strings started from +# are RFC-strings, not to be commited of course.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
First of all, I think we may need some improvemnts on details and wording
here and there, but the format in general looks quite reasonable to me
(at the first sight at least).
still. Generally, a dirty bitmap has some reference point, that is the
state of the disk when the bitmap was cleared or created. For instance,
for incremental backups, whenever you create a backup based on a dirty
bitmap, the dirty bitmap is cleared and the backup target is then said
reference point.
I think it would be nice to put that reference point (i.e. the name of
an image file that contains the clean image) into the dirty bitmap
header, if possible.
I don't think it's a valid assumption that the reference point has a
file name.
+ 19: granularity_bits
+ Granularity bits. Valid values are: 0 - 31.
+# Now, qemu allows creating bitmaps with granularity as a 32bit value. And
+# there are no reasons of increasing it.
Good (implicit) question. I can't imagine any reason for wanting to have
a coarser granularity than 2 GB, but I do think there may be a need in
the future for some people.
Once again, I think we should discriminate between what is generally a
useful limitation and what is simply due to qemu not supporting anything
else right now.
Thus, I think it would be better to increase the range to 0 - 63 and
make a note that qemu only supports values up to 31 right now.
Why 63 and not 255 (the maximum for this one-byte field)? As soon as we
pick an arbitrary value, we can just take whatever qemu actually
supports. We can always increase the limit later.
+
+ variable: The name of the bitmap (not null terminated). Should be
+ unique among all dirty bitmap names within the Dirty
+ bitmaps extension.
+
+ variable: Padding to round up the Dirty Bitmap Directory Entry size
+ to the next multiple of 8.
What I'd like here is variable additional information based on the
bitmap type. For some types, this may be absolutely necessary; for dirty
tracking bitmaps it depends on what we do about the reference point thing.
This could turn out useful, yes.
I also think some extensibility mechanism would be good, like extra_data
in internal snapshots.
The reference point thing is the following: As mentioned at the top, I'd
like there to be some kind of description of what the clean state was.
As far as I know, this is generally a backup in the form of a file. In
that case, we could put that filename here.
Who says that it's a local file? Or that it hasn't been moved since we
created the bitmap?