Hi!

The main feature here is improvement of _next_dirty_area API, which I'm
going to use then for backup / block-copy.

v3: rebase on current master. Mirror don't use _next_dirty_area any
more, so mirror chunks dropped (patches 05 and 07) and 07 commit message
changed.

Vladimir Sementsov-Ogievskiy (10):
  hbitmap: assert that we don't create bitmap larger than INT64_MAX
  hbitmap: move hbitmap_iter_next_word to hbitmap.c
  hbitmap: unpublish hbitmap_iter_skip_words
  hbitmap: drop meta bitmaps as they are unused
  block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
  block/dirty-bitmap: add _next_dirty API
  block/dirty-bitmap: improve _next_dirty_area API
  nbd/server: introduce NBDExtentArray
  nbd/server: use bdrv_dirty_bitmap_next_dirty_area
  block/qcow2-bitmap: use bdrv_dirty_bitmap_next_dirty

 include/block/dirty-bitmap.h |   9 +-
 include/qemu/hbitmap.h       |  97 +++--------
 block/dirty-bitmap.c         |  16 +-
 block/qcow2-bitmap.c         |  11 +-
 nbd/server.c                 | 242 +++++++++++++--------------
 tests/test-hbitmap.c         | 314 +++++++++++++----------------------
 util/hbitmap.c               | 133 +++++++++------
 7 files changed, 366 insertions(+), 456 deletions(-)

-- 
2.21.0

ping

19.12.2019 13:03, Vladimir Sementsov-Ogievskiy wrote:
> Hi!
> 
> The main feature here is improvement of _next_dirty_area API, which I'm
> going to use then for backup / block-copy.
> 
> v3: rebase on current master. Mirror don't use _next_dirty_area any
> more, so mirror chunks dropped (patches 05 and 07) and 07 commit message
> changed.
> 
> Vladimir Sementsov-Ogievskiy (10):
>    hbitmap: assert that we don't create bitmap larger than INT64_MAX
>    hbitmap: move hbitmap_iter_next_word to hbitmap.c
>    hbitmap: unpublish hbitmap_iter_skip_words
>    hbitmap: drop meta bitmaps as they are unused
>    block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
>    block/dirty-bitmap: add _next_dirty API
>    block/dirty-bitmap: improve _next_dirty_area API
>    nbd/server: introduce NBDExtentArray
>    nbd/server: use bdrv_dirty_bitmap_next_dirty_area
>    block/qcow2-bitmap: use bdrv_dirty_bitmap_next_dirty
> 
>   include/block/dirty-bitmap.h |   9 +-
>   include/qemu/hbitmap.h       |  97 +++--------
>   block/dirty-bitmap.c         |  16 +-
>   block/qcow2-bitmap.c         |  11 +-
>   nbd/server.c                 | 242 +++++++++++++--------------
>   tests/test-hbitmap.c         | 314 +++++++++++++----------------------
>   util/hbitmap.c               | 133 +++++++++------
>   7 files changed, 366 insertions(+), 456 deletions(-)
> 


-- 
Best regards,
Vladimir

On 19.12.19 11:03, Vladimir Sementsov-Ogievskiy wrote:
> Hi!
> 
> The main feature here is improvement of _next_dirty_area API, which I'm
> going to use then for backup / block-copy.

Looks good to me overall, with a few minor changes.  I’d rather leave
patches 8 and 9 to Eric, though.  (Even though I’m not exactly the
maintainer for the rest of the patches either...)

Max

20.01.2020 17:20, Max Reitz wrote:
> On 19.12.19 11:03, Vladimir Sementsov-Ogievskiy wrote:
>> Hi!
>>
>> The main feature here is improvement of _next_dirty_area API, which I'm
>> going to use then for backup / block-copy.
> 
> Looks good to me overall, with a few minor changes.  I’d rather leave
> patches 8 and 9 to Eric, though.  (Even though I’m not exactly the
> maintainer for the rest of the patches either...)
> 
> Max
> 

Thanks for reviewing! Let's wait for Eric.

-- 
Best regards,
Vladimir

On 1/20/20 10:33 AM, Vladimir Sementsov-Ogievskiy wrote:
> 20.01.2020 17:20, Max Reitz wrote:
>> On 19.12.19 11:03, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi!
>>>
>>> The main feature here is improvement of _next_dirty_area API, which I'm
>>> going to use then for backup / block-copy.
>>
>> Looks good to me overall, with a few minor changes.  I’d rather leave
>> patches 8 and 9 to Eric, though.  (Even though I’m not exactly the
>> maintainer for the rest of the patches either...)
>>
>> Max
>>
> 
> Thanks for reviewing! Let's wait for Eric.

I had enough concerns over 8/10 to probably warrant a v4; but I'm also 
fine taking the entire series through my NBD tree once everyone is happy 
with it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org