On 12/07/2015 12:59 AM, Fam Zheng wrote: > Vladimir, > > This is what I propose to implement meta bitmap. It's implemented in the > HBitmap level to be more efficient, and the interface slightly varies too. >
I missed it: What was wrong with Vladimir's approach / what are the benefits of this approach? > I'd like to use these operations to make dirty bitmap persistence more > efficient too: unchanged dirty bits don't need to be flushed to disk. So I'm > posting this as a separate series for a common base for both sides. > This is a reasonable use of the meta-bitmap strategy in general. Keep in mind Vladimir's approach to Meta bitmaps used a different granularity such that 1 physical bit implied 1 sector needed to be re-transmitted. A meta-bitmap that keeps track of disk flushes may require a different granularity than one used for migration. > Posting as RFC as 2.6 dev phase is just starting, we can still tweak the > interface and/or implementation to fit the need. > > Fam Zheng (3): > HBitmap: Introduce "meta" bitmap to track bit changes > tests: Add test code for meta bitmap > block: Support meta dirty bitmap > > block.c | 46 ++++++++++++++++++++++++++++++- > block/mirror.c | 3 +- > blockdev.c | 3 +- > include/block/block.h | 11 ++++++++ > include/qemu/hbitmap.h | 7 +++++ > migration/block.c | 2 +- > tests/test-hbitmap.c | 74 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > util/hbitmap.c | 22 +++++++++++++++ > 8 files changed, 164 insertions(+), 4 deletions(-) >
