On 06/12/2015 06:28 AM, Stefan Hajnoczi wrote: > On Thu, Jun 11, 2015 at 12:21:31PM -0400, John Snow wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> >> >> On 06/11/2015 09:03 AM, Stefan Hajnoczi wrote: >>> On Thu, Jun 11, 2015 at 01:19:24PM +0300, Vladimir >>> Sementsov-Ogievskiy wrote: >>>> On 10.06.2015 16:24, Stefan Hajnoczi wrote: >>>>> On Wed, Jun 10, 2015 at 11:19:30AM +0300, Vladimir >>>>> Sementsov-Ogievskiy wrote: >>>>>> On 09.06.2015 20:03, Stefan Hajnoczi wrote: >>>>>>> On Mon, Jun 08, 2015 at 06:21:19PM +0300, Vladimir >>>>>>> Sementsov-Ogievskiy wrote: >>>>>>>> @@ -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 >>>>>>> Is there a maximum? >>>>>> hmm. any proposals for this? >>>>> 65535 seems practical. >>>> >>>> So, you suggest to reduce this field width to 2b? And additional >>>> 2 bytes reserved field, to achieve 8b-alignment? >>> >>> No, I would leave it 32-bit but impose a little (which can be > > s/little/limit/ > >>> increased later if necessary). That's how nb_snapshots works too. >>> >> >> Doesn't the code already limit the number of bitmaps via +#define >> QCOW_MAX_DIRTY_BITMAPS 65536, from patch 2? > > It needs to be in the specification. >
Yes, but the way the replies read made it sound like we hadn't decided on what the limit *was*, so I was just trying to clarify for myself, here.
