Re: [Qemu-devel] [PATCH 1/8] spec: add qcow2-dirty-bitmaps specification

[Vladimir Sementsov-Ogievskiy]

Sorry, drop this if you, look at the new version of this litter
On 24.08.2015 16:30, Vladimir Sementsov-Ogievskiy wrote:
> About structs and constraints:
>
> Optional Header:
>
> 64bit nb_dirty_bitmaps
>     valid: 1 - 65536. I think here should not be 0, in this case 
> dirty-bitmap-optional-header should not exist at all. Should it 
> instead be 0 - 65536
> 64bit dirty_bitmaps_offset
>     valid: any, but dirty_bitmaps_offset % cluster_size = 0
>
> Dirty BItmap Directory Enrty ( = bitmap header):
>
> 64bit dirty_bitmap_table_offset
>     valid: any, but dirty_bitmaps_offset % cluster_size = 0
> 64bit nb_virtual_bits (before it was called bitmap_size)
>     valid: no direct constraints (as for disk size), but it should be 
> less then dirty_bitmap_table_size * cluster_size * 8 * bitmap_granularity
> 32bit dirty_bitmap_table_size
>     ? The bitmap will take ~ dirty_bitmap_table_size * cluster_size 
> bytes in RAM. What the limit should be for it?
> 32bit bitmap_granularity_bits ( before it was bitmap_granularity)
>     valid; 0 - 63 (as for HBitmap)
>     (1 << bitmap_granularity_bits) is number of virtual bits in one 
> physical bit. Not related to sectors/bytes, etc. Let this format be 
> closer to HBitmap than to BdrvDirtyBitmap
> 16bit name_size
>     valid: 1 - 1023. // should it be 0 - 1023 ?
> /* name follows */
> /* offset to 8 bytes boundary follows */
>
> On 08.06.2015 18:21, Vladimir Sementsov-Ogievskiy wrote:
> > From: Vladimir Sementsov-Ogievskiy <address@hidden>
> >
> > Persistent dirty bitmaps will be saved into qcow2 files. It may be used
> > as 'internal' bitmaps (for qcow2 drives) or as 'external' bitmaps for
> > other drives (there may be qcow2 file with zero disk size but with
> > several dirty bitmaps for other drives).
> >
> > Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> > ---
> >   docs/specs/qcow2.txt | 66 
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 66 insertions(+)
> >
> > diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
> > index 121dfc8..0fffba2 100644
> > --- a/docs/specs/qcow2.txt
> > +++ b/docs/specs/qcow2.txt
> > @@ -123,6 +123,7 @@ be stored. Each extension has a structure like 
> > the following:
> >                           0x00000000 - End of the header extension area
> >                           0xE2792ACA - Backing file format name
> >                           0x6803f857 - Feature name table
> > +                        0x23852875 - Dirty bitmaps
> >                           other      - Unknown header extension, can 
> > be safely
> >                                        ignored
> >   @@ -166,6 +167,19 @@ the header extension data. Each entry look 
> > like this:
> >                       terminated if it has full length)
> >     +== Dirty bitmaps ==
> > +
> > +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
> > +
> > +          4 - 11:  dirty_bitmaps_offset
> > +                   Offset into the image file at which the dirty 
> > bitmaps table
> > +                   starts. Must be aligned to a cluster boundary.
> > +
> > +
> >   == Host cluster management ==
> >     qcow2 manages the allocation of host clusters by maintaining a 
> > reference count
> > @@ -360,3 +374,55 @@ Snapshot table entry:
> >             variable:   Padding to round up the snapshot table entry 
> > size to the
> >                       next multiple of 8.
> > +
> > +
> > +== Dirty bitmaps ==
> > +
> > +The feature supports storing several dirty bitmaps in the qcow2 file.
> > +
> > +=== Cluster mapping ===
> > +
> > +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.
> > +
> > +Given an offset into the bitmap, the offset into the image file can be
> > +obtained as follows:
> > +
> > +    offset = l1_table[offset / cluster_size] + (offset % cluster_size)
> > +
> > +L1 table entry:
> > +
> > +    Bit  0 -  61:   Standard cluster descriptor
> > +
> > +        62 -  63:   Reserved
> > +
> > +=== Bitmap table ===
> > +
> > +A directory of all bitmaps is stored in the bitmap table, a 
> > contiguous area in
> > +the image file, whose starting offset and length are given by the 
> > header fields
> > +dirty_bitmaps_offset and nb_dirty_bitmaps. The entries of the bitmap 
> > table have
> > +variable length, depending on the length of name and extra data.
> > +
> > +Bitmap table entry:
> > +
> > +    Byte 0 -  7:    Offset into the image file at which the L1 table 
> > for the
> > +                    bitmap starts. Must be aligned to a cluster 
> > boundary.
> > +
> > +         8 - 11:    Number of entries in the L1 table of the bitmap
> > +
> > +        12 - 15:    Bitmap granularity in bytes
> > +
> > +        16 - 23:    Bitmap size in sectors
> > +
> > +        24 - 25:    Size of the bitmap name
> > +
> > +        variable:   The name of the bitmap (not null terminated)
> > +
> > +        variable:   Padding to round up the bitmap table entry size 
> > to the
> > +                    next multiple of 8.
> > +
> > +The fields "size", "granularity" and "name" are corresponding with 
> > the fields
> > +in struct BdrvDirtyBitmap.


--
Best regards,
Vladimir
* now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.