qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH for 2.6 2/3] block: Hide HBitmap in


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH for 2.6 2/3] block: Hide HBitmap in block dirty bitmap interface
Date: Tue, 24 Nov 2015 12:12:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

On 24.11.2015 05:28, Fam Zheng wrote:
On Mon, 11/23 16:34, John Snow wrote:
Hmm, what's the idea, here?

This patch does a lot more than just hide hbitmap details from callers
of block_dirty_bitmap functions.

So we're changing the backing hbitmap to always be one where g=0 and the
number of physical bits directly is (now) the same as the number of
'virtual' bits, pre-patch. Then, to compensate, we handle the shift math
to convert the bitmap granularity to sector size and vice-versa in the
Block Dirty Bitmap layer instead of in the hbitmap layer.

What's the benefit? It looks like we just pull all the implementation
details up from hbitmap and into BdrvDirtyBitmap, which I am not
immediately convinced of as being a benefit.
It feels counter intuitive to me with hbitmap handling granularity, it makes it
more like a HGranularityBitmap rather than HBitmap, and is unnecessarily
complex to work on.

Now it's simplified in that only one BdrvDirtyBitmap needs to care about the
granularity, and which I think is a big benefit when we are going to extend the
dirty bitmap interface, for example to serialize and deserialize for
persistence.

Fam

But what is the relation from this to adding iterator interface? This seems like this patch do two different things:
1) granularity changes, described in quotation above
2) adding iterator related things, described in commit message

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]