[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirr
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror |
Date: |
Wed, 10 May 2017 11:00:16 -0400 |
User-agent: |
Mutt/1.8.0 (2017-02-23) |
On Wed, May 10, 2017 at 03:25:31PM +0200, Denis V. Lunev wrote:
> On 05/09/2017 06:52 PM, Stefan Hajnoczi wrote:
> > On Mon, May 08, 2017 at 05:07:18PM -0400, John Snow wrote:
> >>
> >> On 05/08/2017 05:02 PM, Denis V. Lunev wrote:
> >>> On 05/08/2017 10:35 PM, Stefan Hajnoczi wrote:
> >>>> On Thu, May 04, 2017 at 12:54:40PM +0200, Daniel Kucera wrote:
> >>>>
> >>>> Seems like a logical extension along the same lines as the backup block
> >>>> job's dirty bitmap sync mode.
> >>>>
> >>>>> parameter bitmap chooses existing dirtymap instead of newly created
> >>>>> in mirror_start_job
> >>>>>
> >>>>> Signed-off-by: Daniel Kucera <address@hidden>
> >>> Can you pls describe the use case pls in a bit more details.
> >>>
> >>> For now this could be a bit strange:
> >>> - dirty bitmap, which can be found via bdrv_create_dirty_bitmap
> >>> could be read-only or read-write, i.e. being modified by writes
> >>> or be read-only, which should not be modified. Thus adding
> >>> r/o bitmap to the mirror could result in interesting things.
> >>>
> >> This patch as it was submitted does not put the bitmap into a read-only
> >> mode; it leaves it RW and modifies it as it processes the mirror command.
> >>
> >> Though you do raise a good point; this bitmap is now in-use by a job and
> >> should not be allowed to be deleted by the user, but our existing
> >> mechanism treats a locked bitmap as one that is also in R/O mode. This
> >> would be a different use case.
> >>
> >>> Minimally we should prohibit usage of r/o bitmaps this way.
> >>>
> >>> So, why to use mirror, not backup for the case?
> >>>
> >> My guess is for pivot semantics.
> > Daniel posted his workflow in a previous revision of this series:
> >
> > He is doing a variation on non-shared storage migration with the mirror
> > block job, but using the ZFS send operation to transfer the initial copy
> > of the disk.
> >
> > Once ZFS send completes it's necessary to transfer all the blocks that
> > were dirtied while the transfer was taking place.
> >
> > 1. Create dirty bitmap and start tracking dirty blocks in QEMU.
> > 2. Snapshot and send ZFS volume.
> > 3. mirror sync=bitmap after ZFS send completes.
> > 4. Live migrate.
> >
> > Stefan
> thank you very much. This is clear now.
>
> If I am not mistaken, this can be very easy done with
> the current implementation without further QEMU modifications.
> Daniel just needs to start mirror and put it on pause for the
> duration of stage (2).
>
> Will this work?
I think it's a interesting idea but I'm not sure if sync=none + pause
can be done atomically. Without atomicity a block might be sent to the
destination while the ZFS send is still in progress.
Stefan
signature.asc
Description: PGP signature
- [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Daniel Kucera, 2017/05/04
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Stefan Hajnoczi, 2017/05/08
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Denis V. Lunev, 2017/05/08
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, John Snow, 2017/05/08
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Stefan Hajnoczi, 2017/05/09
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Denis V. Lunev, 2017/05/10
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror,
Stefan Hajnoczi <=
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Denis V. Lunev, 2017/05/10
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Daniel Kučera, 2017/05/11
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Denis V. Lunev, 2017/05/11
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Daniel Kučera, 2017/05/11
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Stefan Hajnoczi, 2017/05/11
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, John Snow, 2017/05/11
- Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror, Denis V. Lunev, 2017/05/11