[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 08/13] block: Support meta dirty bitmap
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [PATCH v2 08/13] block: Support meta dirty bitmap |
Date: |
Tue, 26 Jan 2016 16:23:59 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, 01/26 10:49, Vladimir Sementsov-Ogievskiy wrote:
> On 26.01.2016 09:25, Fam Zheng wrote:
> >On Fri, 01/22 15:05, Vladimir Sementsov-Ogievskiy wrote:
> >>>In my migration series I need iterators, get granularity, and
> >>>something like hbitmap_count for meta bitmaps. You can add them
> >>>here if you want, or I can add them in my series.
> >Okay, I can add that.
> >
> >I have one more question on the interface: what dirty bitmaps are going to be
> >migrated? At this moment there are dirty bitmaps created by block jobs
> >(drive-mirror), and in-memory dirty bitmaps created for incremental backup;
> >later there will be persistent dirty bitmaps owned by block drivers (extended
> >version of qcow2, and in QBM driver I'm working on). Which of them are
> >subject
> >of migration in your series?
> >
> >I'm asking because I want to know whether we need to implement multiple meta
> >bitmaps on one block dirty bitmap.
> >
> >Fam
> Only named bitmaps are migrated. For now, only qmp-created bitmaps
> are named. So, it can be in-memory dirty bitmaps or, in future,
> persistent dirty bitmaps.
>
> Why multiple meta bitmaps?
The complication is from combining persistence and migration of a dirty bitmap.
To begin with, persistence drivers (qcow2 or QBM) would need meta dirty bitmaps
to avoid writing unchanged dirty bit ranges to disk, just like in migration.
This means if the persisted named dirty bitmap is being migrated, both the
block driver and migration code will then need their own meta dirty bitmaps,
that is where the question rose.
One step back, we haven't sorted out "migrating persistent dirty bitmap" at all
(see below). So it's probably okay to disallow that as the first step.
P.S. For discussion, I think we ultimately want users to be able to continue
their incremental backup even across the migration point. If they're using
shared storage, I think it is possible even without dirty bitmap migration, by
flushing the dirty bitmap at src side then loading it at dest side. Otherwise
it is trickier as we will have to migrate the persisted dirty bitmap - the dest
side must use a capable format, and we need to check this capability when
migration starts. By that time, the meta dirty bitmap interface can be
extended to allow at least two meta bitmaps on the same dirty bitmap.
Fam
- [Qemu-devel] [PATCH v2 06/13] HBitmap: Introduce "meta" bitmap to track bit changes, (continued)
Re: [Qemu-devel] [PATCH v2 08/13] block: Support meta dirty bitmap, John Snow, 2016/01/25
[Qemu-devel] [PATCH v2 09/13] block: Add two dirty bitmap getters, Fam Zheng, 2016/01/20
[Qemu-devel] [PATCH v2 10/13] block: Assert that bdrv_release_dirty_bitmap succeeded, Fam Zheng, 2016/01/20
[Qemu-devel] [PATCH v2 11/13] hbitmap: serialization, Fam Zheng, 2016/01/20
[Qemu-devel] [PATCH v2 12/13] block: BdrvDirtyBitmap serialization interface, Fam Zheng, 2016/01/20
[Qemu-devel] [PATCH v2 13/13] tests: Add test code for hbitmap serialization, Fam Zheng, 2016/01/20