[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [PATCH v4 1/2] live-block-ops.txt: Rename,
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-devel] [Qemu-block] [PATCH v4 1/2] live-block-ops.txt: Rename, rewrite, and improve it |
Date: |
Thu, 29 Jun 2017 14:28:55 +0200 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
On Wed 28 Jun 2017 04:58:00 PM CEST, Kashyap Chamarthy wrote:
> +Once a 'mirror' job has started, there are two possible actions when a
> +``drive-mirror`` job is active:
> +
> +1. Issuing the command ``block-job-cancel``: will, after completing
> + synchronization of the content from the disk image chain to the
> + target image, [E] -- create a point-in-time (which is at the time of
> + *triggering* the cancel command) copy, contained in image [E], of the
> + backing file.
A point-in-time [...] copy [...] of the backing file ? That would be a
copy of the whole chain or the topmost image (depending on the sync
mode).
> +The ``"sync": "full"``, from the above, means: copy the *entire* chain
> +to the destination.
I think it's in general a good idea to describe the different sync modes
before doing this, because they're not completely obvious when you first
try to use these commands.
> +Notes on ``blockdev-mirror``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
> +(1) Create the target image (using ``qemu-img``), say, backup.qcow2
If we're doing a mirror here, backup.qcow2 is probably not the best
name :-)
> +Live disk backup --- ``drive-backup`` and ``blockdev-backup``
> +-------------------------------------------------------------
> +
> +The ``drive-backup`` (and its newer equivalent ``blockdev-backup``) allows
> +you to create a point-in-time snapshot.
> +
> +In this case, the point-in-time is when you *start* the ``drive-backup``
> +(or its newer equivalent ``blockdev-backup``) command.
> +
> +Currently, there are four different types of synchronization modes:
> +
> +(1) ``full`` -- Synchronize the content of entire disk image chain to
> + the target
> +(2) ``top`` -- Synchronize only the contents of the top-most disk image
> + in the chain to the target
> +(3) ``none`` -- Synchronize only the new writes from this point on
> +(4) ``incremental`` -- Synchronize content that is described by the
> + dirty bitmap
Here's the kind of summary of the different sync modes that I was
talking about earlier.
One note about sync=none, though. If I'm not wrong drive-backup makes a
point-in-time copy of the data at the moment when the command is issued
(that's one difference from drive-mirror). Therefore drive-backup never
synchronizes "new writes from this point on".
I don't think that drive-backup sync=none copies any data then, can
anyone clarify?
The rest of the document looks good to me, thanks!
Berto
- [Qemu-devel] [PATCH v4 0/2] Rewrite 'live-block-ops.txt'; convert 'bitmaps.md' to rST, Kashyap Chamarthy, 2017/06/28
- [Qemu-devel] [PATCH v4 0/2] Rewrite 'live-block-ops.txt'; convert 'bitmaps.md' to rST, Kashyap Chamarthy, 2017/06/28
- [Qemu-devel] [PATCH v4 1/2] live-block-ops.txt: Rename, rewrite, and improve it, Kashyap Chamarthy, 2017/06/28
- Re: [Qemu-devel] [Qemu-block] [PATCH v4 1/2] live-block-ops.txt: Rename, rewrite, and improve it, Alberto Garcia, 2017/06/28
- Re: [Qemu-devel] [Qemu-block] [PATCH v4 1/2] live-block-ops.txt: Rename, rewrite, and improve it, Eric Blake, 2017/06/28
- Re: [Qemu-devel] [Qemu-block] [PATCH v4 1/2] live-block-ops.txt: Rename, rewrite, and improve it, Alberto Garcia, 2017/06/29
- Re: [Qemu-devel] [Qemu-block] [PATCH v4 1/2] live-block-ops.txt: Rename, rewrite, and improve it,
Alberto Garcia <=
- [Qemu-devel] [PATCH v4 2/2] bitmaps.md: Convert to rST; move it into 'interop' dir, Kashyap Chamarthy, 2017/06/28