[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH 6/8] docs: Document how to stream to an intermed
From: |
Eric Blake |
Subject: |
Re: [Qemu-block] [PATCH 6/8] docs: Document how to stream to an intermediate layer |
Date: |
Wed, 22 Apr 2015 13:27:31 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
On 04/16/2015 09:12 AM, Alberto Garcia wrote:
> Signed-off-by: Alberto Garcia <address@hidden>
> ---
> docs/live-block-ops.txt | 30 +++++++++++++++++++-----------
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/docs/live-block-ops.txt b/docs/live-block-ops.txt
> index a257087..3bf86be 100644
> --- a/docs/live-block-ops.txt
> +++ b/docs/live-block-ops.txt
> @@ -10,9 +10,9 @@ Snapshot live merge
> Given a snapshot chain, described in this document in the following
> format:
>
> -[A] -> [B] -> [C] -> [D]
> +[A] -> [B] -> [C] -> [D] -> [E]
I think on the list we've mostly settled on a notation where we express
this relation as:
[A] <- [B]
that is, the symbol "<-" makes more sense as "serves as a backing file
of" than "->", so that you end up reading the relationship as "[A]
serves as a backing of [B]" (or read right-to-left as "[B] has a backing
file of [A]").
Of course, the direction of the arrows is pre-existing, so it doesn't
hold up this patch, but we probably ought to scrub our examples to
consistently use <-.
>
> -Where the rightmost object ([D] in the example) described is the current
> +Where the rightmost object ([E] in the example) described is the current
> image which the guest OS has write access to. To the left of it is its base
> image, and so on accordingly until the leftmost image, which has no
> base.
> @@ -21,11 +21,13 @@ The snapshot live merge operation transforms such a chain
> into a
> smaller one with fewer elements, such as this transformation relative
> to the first example:
>
> -[A] -> [D]
> +[A] -> [E]
>
> -Currently only forward merge with target being the active image is
> -supported, that is, data copy is performed in the right direction with
> -destination being the rightmost image.
> +Data is copied in the right direction with destination being the
> +rightmost image, but any other intermediate image can be specified
> +instead, for instance from [B] into [D]:
> +
> +[A] -> [B] -> [D] -> [E]
Should you really describe that as moving data from [B] into [D], or
would it be better to describe it as moving the data from [C] into [D]
such that [D] can now be backed by [B] instead of [C]?
I don't know if it is worth a tweak, and modulo my question on this one
sentence, I think you've done a good job documenting the feature
addition, so:
Reviewed-by: Eric Blake <address@hidden>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-block] [PATCH v4 0/8] Support streaming to an intermediate layer, Alberto Garcia, 2015/04/16
- [Qemu-block] [PATCH 2/8] block: allow block jobs in any arbitrary node, Alberto Garcia, 2015/04/16
- [Qemu-block] [PATCH 6/8] docs: Document how to stream to an intermediate layer, Alberto Garcia, 2015/04/16
- [Qemu-block] [PATCH 5/8] block: Add QMP support for streaming to an intermediate layer, Alberto Garcia, 2015/04/16
- [Qemu-block] [PATCH 8/8] qemu-iotests: test streaming to an intermediate layer, Alberto Garcia, 2015/04/16
- [Qemu-block] [PATCH 3/8] block: never cancel a streaming job without running stream_complete(), Alberto Garcia, 2015/04/16
- [Qemu-block] [PATCH 4/8] block: Support streaming to an intermediate layer, Alberto Garcia, 2015/04/16
- [Qemu-block] [PATCH 1/8] block: keep a list of block jobs, Alberto Garcia, 2015/04/16