#
a4d5224c |
| 02-Feb-2023 |
Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> |
hbitmap: fix hbitmap_status() return value for first dirty bit case
The last return statement should return true, as we already evaluated that start == next_dirty
Also, fix hbitmap_status() descrip
hbitmap: fix hbitmap_status() return value for first dirty bit case
The last return statement should return true, as we already evaluated that start == next_dirty
Also, fix hbitmap_status() description in header
Cc: qemu-stable@nongnu.org Fixes: a6426475a75 ("block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()") Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> Message-Id: <20230202181523.423131-1-andrey.zhadchenko@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
#
a4d5224c |
| 02-Feb-2023 |
Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> |
hbitmap: fix hbitmap_status() return value for first dirty bit case
The last return statement should return true, as we already evaluated that start == next_dirty
Also, fix hbitmap_status() descrip
hbitmap: fix hbitmap_status() return value for first dirty bit case
The last return statement should return true, as we already evaluated that start == next_dirty
Also, fix hbitmap_status() description in header
Cc: qemu-stable@nongnu.org Fixes: a6426475a75 ("block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()") Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> Message-Id: <20230202181523.423131-1-andrey.zhadchenko@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
#
a4d5224c |
| 02-Feb-2023 |
Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> |
hbitmap: fix hbitmap_status() return value for first dirty bit case
The last return statement should return true, as we already evaluated that start == next_dirty
Also, fix hbitmap_status() descrip
hbitmap: fix hbitmap_status() return value for first dirty bit case
The last return statement should return true, as we already evaluated that start == next_dirty
Also, fix hbitmap_status() description in header
Cc: qemu-stable@nongnu.org Fixes: a6426475a75 ("block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()") Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> Message-Id: <20230202181523.423131-1-andrey.zhadchenko@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
618af89e |
| 17-May-2022 |
Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org> |
block: simplify handling of try to merge different sized bitmaps
We have too much logic to simply check that bitmaps are of the same size. Let's just define that hbitmap_merge() and bdrv_dirty_bitma
block: simplify handling of try to merge different sized bitmaps
We have too much logic to simply check that bitmaps are of the same size. Let's just define that hbitmap_merge() and bdrv_dirty_bitmap_merge_internal() require their argument bitmaps be of same size, this simplifies things.
Let's look through the callers:
For backup_init_bcs_bitmap() we already assert that merge can't fail.
In bdrv_reclaim_dirty_bitmap_locked() we gracefully handle the error that can't happen: successor always has same size as its parent, drop this logic.
In bdrv_merge_dirty_bitmap() we already has assertion and separate check. Make the check explicit and improve error message.
Signed-off-by: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru> Reviewed-by: Nikita Lapshin <nikita.lapshin@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220517111206.23585-4-v.sementsov-og@mail.ru> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
618af89e |
| 17-May-2022 |
Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org> |
block: simplify handling of try to merge different sized bitmaps
We have too much logic to simply check that bitmaps are of the same size. Let's just define that hbitmap_merge() and bdrv_dirty_bitma
block: simplify handling of try to merge different sized bitmaps
We have too much logic to simply check that bitmaps are of the same size. Let's just define that hbitmap_merge() and bdrv_dirty_bitmap_merge_internal() require their argument bitmaps be of same size, this simplifies things.
Let's look through the callers:
For backup_init_bcs_bitmap() we already assert that merge can't fail.
In bdrv_reclaim_dirty_bitmap_locked() we gracefully handle the error that can't happen: successor always has same size as its parent, drop this logic.
In bdrv_merge_dirty_bitmap() we already has assertion and separate check. Make the check explicit and improve error message.
Signed-off-by: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru> Reviewed-by: Nikita Lapshin <nikita.lapshin@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220517111206.23585-4-v.sementsov-og@mail.ru> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
Revision tags: v7.0.0, v7.0.0-rc4, v7.0.0-rc3, v7.0.0-rc2, v7.0.0-rc1, v7.0.0-rc0 |
|
#
b21e2380 |
| 15-Mar-2022 |
Markus Armbruster <armbru@redhat.com> |
Use g_new() & friends where that makes obvious sense
g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two, i
Use g_new() & friends where that makes obvious sense
g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer, for two reasons. One, it catches multiplication overflowing size_t. Two, it returns T * rather than void *, which lets the compiler catch more type errors.
This commit only touches allocations with size arguments of the form sizeof(T).
Patch created mechanically with:
$ spatch --in-place --sp-file scripts/coccinelle/use-g_new-etc.cocci \ --macro-file scripts/cocci-macro-file.h FILES...
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20220315144156.1595462-4-armbru@redhat.com> Reviewed-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru>
show more ...
|
#
a6426475 |
| 03-Mar-2022 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()
Add a convenient function similar with bdrv_block_status() to get status of dirty bitmap.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vseme
block/dirty-bitmap: introduce bdrv_dirty_bitmap_status()
Add a convenient function similar with bdrv_block_status() to get status of dirty bitmap.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220303194349.2304213-9-vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
show more ...
|
Revision tags: v6.1.1, v6.2.0, v6.2.0-rc4, v6.2.0-rc3, v6.2.0-rc2, v6.2.0-rc1, v6.2.0-rc0, v6.0.1, v6.1.0, v6.1.0-rc4, v6.1.0-rc3, v6.1.0-rc2, v6.1.0-rc1, v6.1.0-rc0, v6.0.0, v6.0.0-rc5, v6.0.0-rc4, v6.0.0-rc3, v6.0.0-rc2, v6.0.0-rc1, v6.0.0-rc0, v5.2.0, v5.2.0-rc4, v5.2.0-rc3, v5.2.0-rc2, v5.2.0-rc1, v5.2.0-rc0, v5.0.1, v5.1.0, v5.1.0-rc3, v5.1.0-rc2, v5.1.0-rc1, v5.1.0-rc0, v4.2.1, v5.0.0, v5.0.0-rc4, v5.0.0-rc3, v5.0.0-rc2, v5.0.0-rc1, v5.0.0-rc0 |
|
#
299ea9ff |
| 05-Feb-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
block/dirty-bitmap: improve _next_dirty_area API
Firstly, _next_dirty_area is for scenarios when we may contiguously search for next dirty area inside some limited region, so it is more comfortable
block/dirty-bitmap: improve _next_dirty_area API
Firstly, _next_dirty_area is for scenarios when we may contiguously search for next dirty area inside some limited region, so it is more comfortable to specify "end" which should not be recalculated on each iteration.
Secondly, let's add a possibility to limit resulting area size, not limiting searching area. This will be used in NBD code in further commit. (Note that now bdrv_dirty_bitmap_next_dirty_area is unused)
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200205112041.6003-8-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
9399c54b |
| 05-Feb-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
block/dirty-bitmap: add _next_dirty API
We have bdrv_dirty_bitmap_next_zero, let's add corresponding bdrv_dirty_bitmap_next_dirty, which is more comfortable to use than bitmap iterators in some case
block/dirty-bitmap: add _next_dirty API
We have bdrv_dirty_bitmap_next_zero, let's add corresponding bdrv_dirty_bitmap_next_dirty, which is more comfortable to use than bitmap iterators in some cases.
For test modify test_hbitmap_next_zero_check_range to check both next_zero and next_dirty and add some new checks.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200205112041.6003-7-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
642700fd |
| 05-Feb-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
We are going to introduce bdrv_dirty_bitmap_next_dirty so that same variable may be used to store its return value and to be its
block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
We are going to introduce bdrv_dirty_bitmap_next_dirty so that same variable may be used to store its return value and to be its parameter, so it would int64_t.
Similarly, we are going to refactor hbitmap_next_dirty_area to use hbitmap_next_dirty together with hbitmap_next_zero, therefore we want hbitmap_next_zero parameter type to be int64_t too.
So, for convenience update all parameters of *_next_zero and *_next_dirty_area to be int64_t.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200205112041.6003-6-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
0c88f197 |
| 05-Feb-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
hbitmap: drop meta bitmaps as they are unused
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.c
hbitmap: drop meta bitmaps as they are unused
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200205112041.6003-5-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
30b8346c |
| 05-Feb-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
hbitmap: unpublish hbitmap_iter_skip_words
Function is internal and even commented as internal. Drop its definition from .h file.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.c
hbitmap: unpublish hbitmap_iter_skip_words
Function is internal and even commented as internal. Drop its definition from .h file.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200205112041.6003-4-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
be24c714 |
| 05-Feb-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
hbitmap: move hbitmap_iter_next_word to hbitmap.c
The function is definitely internal (it's not used by third party and it has complicated interface). Move it to .c file.
Signed-off-by: Vladimir Se
hbitmap: move hbitmap_iter_next_word to hbitmap.c
The function is definitely internal (it's not used by third party and it has complicated interface). Move it to .c file.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200205112041.6003-3-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
6a150995 |
| 05-Feb-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
hbitmap: assert that we don't create bitmap larger than INT64_MAX
We have APIs which returns signed int64_t, to be able to return error. Therefore we can't handle bitmaps with absolute size larger t
hbitmap: assert that we don't create bitmap larger than INT64_MAX
We have APIs which returns signed int64_t, to be able to return error. Therefore we can't handle bitmaps with absolute size larger than (INT64_MAX+1). Still, keep maximum to be INT64_MAX which is a bit safer.
Note, that bitmaps are used to represent disk images, which can't exceed INT64_MAX anyway.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20200205112041.6003-2-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v4.2.0, v4.2.0-rc5, v4.2.0-rc4, v4.2.0-rc3, v4.2.0-rc2, v4.1.1, v4.2.0-rc1, v4.2.0-rc0, v4.0.1 |
|
#
fed33bd1 |
| 11-Oct-2019 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
hbitmap: handle set/reset with zero length
Passing zero length to these functions leads to unpredicted results. Zero-length set/reset may occur in active-mirror, on zero-length write (which is unlik
hbitmap: handle set/reset with zero length
Passing zero length to these functions leads to unpredicted results. Zero-length set/reset may occur in active-mirror, on zero-length write (which is unlikely, but not guaranteed to never happen).
Let's just do nothing on zero-length request.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20191011090711.19940-2-vsementsov@virtuozzo.com Reviewed-by: Max Reitz <mreitz@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
show more ...
|
Revision tags: v3.1.1.1, v4.1.0, v4.1.0-rc5, v4.1.0-rc4 |
|
#
48557b13 |
| 06-Aug-2019 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
util/hbitmap: strict hbitmap_reset
hbitmap_reset has an unobvious property: it rounds requested region up. It may provoke bugs, like in recently fixed write-blocking mode of mirror: user calls reset
util/hbitmap: strict hbitmap_reset
hbitmap_reset has an unobvious property: it rounds requested region up. It may provoke bugs, like in recently fixed write-blocking mode of mirror: user calls reset on unaligned region, not keeping in mind that there are possible unrelated dirty bytes, covered by rounded-up region and information of this unrelated "dirtiness" will be lost.
Make hbitmap_reset strict: assert that arguments are aligned, allowing only one exception when @start + @count == hb->orig_size. It's needed to comfort users of hbitmap_next_dirty_area, which cares about hb->orig_size.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20190806152611.280389-1-vsementsov@virtuozzo.com> [Maintainer edit: Max's suggestions from on-list. --js] [Maintainer edit: Eric's suggestion for aligned macro. --js] Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v3.1.1, v4.1.0-rc3 |
|
#
c5b40c1f |
| 29-Jul-2019 |
John Snow <jsnow@redhat.com> |
hbitmap: enable merging across granularities
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20190709232550.10724-9-jsnow@redhat.com Signed-off-by:
hbitmap: enable merging across granularities
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20190709232550.10724-9-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
3bde4b01 |
| 29-Jul-2019 |
John Snow <jsnow@redhat.com> |
hbitmap: Fix merge when b is empty, and result is not an alias of a
Nobody calls the function like this currently, but we neither prohibit or cope with this behavior. I decided to make the function
hbitmap: Fix merge when b is empty, and result is not an alias of a
Nobody calls the function like this currently, but we neither prohibit or cope with this behavior. I decided to make the function cope with it.
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20190709232550.10724-8-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
4e4de222 |
| 05-Aug-2019 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
util/hbitmap: update orig_size on truncate
Without this, hbitmap_next_zero and hbitmap_next_dirty_area are broken after truncate. So, orig_size is broken since it's introduction in 76d570dc495c56bb.
util/hbitmap: update orig_size on truncate
Without this, hbitmap_next_zero and hbitmap_next_dirty_area are broken after truncate. So, orig_size is broken since it's introduction in 76d570dc495c56bb.
Fixes: 76d570dc495c56bb Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190805120120.23585-1-vsementsov@virtuozzo.com Reviewed-by: Max Reitz <mreitz@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
show more ...
|
Revision tags: v4.1.0-rc2, v4.1.0-rc1, v4.1.0-rc0, v4.0.0, v4.0.0-rc4, v3.0.1, v4.0.0-rc3, v4.0.0-rc2, v4.0.0-rc1, v4.0.0-rc0 |
|
#
19c021e1 |
| 15-Jan-2019 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
Revert "hbitmap: Add @advance param to hbitmap_iter_next()"
This reverts commit a33fbb4f8b64226becf502a123733776ce319b24.
The functionality is unused.
Note: in addition to automatic revert, drop s
Revert "hbitmap: Add @advance param to hbitmap_iter_next()"
This reverts commit a33fbb4f8b64226becf502a123733776ce319b24.
The functionality is unused.
Note: in addition to automatic revert, drop second parameter in hbitmap_iter_next() call from hbitmap_next_dirty_area() too.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
show more ...
|
#
a78a1a48 |
| 15-Jan-2019 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
dirty-bitmap: add bdrv_dirty_bitmap_next_dirty_area
The function alters bdrv_dirty_iter_next_area(), which is wrong and less efficient (see further commit "block/mirror: fix and improve do_sync_targ
dirty-bitmap: add bdrv_dirty_bitmap_next_dirty_area
The function alters bdrv_dirty_iter_next_area(), which is wrong and less efficient (see further commit "block/mirror: fix and improve do_sync_target_write" for description).
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
show more ...
|
#
76d570dc |
| 15-Jan-2019 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
dirty-bitmap: improve bdrv_dirty_bitmap_next_zero
Add bytes parameter to the function, to limit searched range.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
|
Revision tags: v3.1.0, v3.1.0-rc5, v3.1.0-rc4, v3.1.0-rc3, v3.1.0-rc2, v3.1.0-rc1, v3.1.0-rc0 |
|
#
d1dde714 |
| 29-Oct-2018 |
Eric Blake <eblake@redhat.com> |
bitmap: Update count after a merge
We need an accurate count of the number of bits set in a bitmap after a merge. In particular, since the merge operation short-circuits a merge from an empty source
bitmap: Update count after a merge
We need an accurate count of the number of bits set in a bitmap after a merge. In particular, since the merge operation short-circuits a merge from an empty source, if you have bitmaps A, B, and C where B started empty, then merge C into B, and B into A, an inaccurate count meant that A did not get the contents of C.
In the worst case, we may falsely regard the bitmap as empty when it has had new writes merged into it.
Fixes: be58721db CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20181002233314.30159-1-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
show more ...
|
#
fa000f2f |
| 29-Oct-2018 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
dirty-bitmap: make it possible to restore bitmap after merge
Add backup parameter to bdrv_merge_dirty_bitmap() to be used then with bdrv_restore_dirty_bitmap() if it needed to restore the bitmap aft
dirty-bitmap: make it possible to restore bitmap after merge
Add backup parameter to bdrv_merge_dirty_bitmap() to be used then with bdrv_restore_dirty_bitmap() if it needed to restore the bitmap after merge operation.
This is needed to implement bitmap merge transaction action in further commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com>
show more ...
|
Revision tags: v3.0.0, v3.0.0-rc4, v2.12.1, v3.0.0-rc3, v3.0.0-rc2, v3.0.0-rc1, v3.0.0-rc0, v2.11.2 |
|
#
a33fbb4f |
| 13-Jun-2018 |
Max Reitz <mreitz@redhat.com> |
hbitmap: Add @advance param to hbitmap_iter_next()
This new parameter allows the caller to just query the next dirty position without moving the iterator.
Signed-off-by: Max Reitz <mreitz@redhat.co
hbitmap: Add @advance param to hbitmap_iter_next()
This new parameter allows the caller to just query the next dirty position without moving the iterator.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20180613181823.13618-8-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
show more ...
|