| Message ID | 20461b471d6f38f4488957563b7999751e73b8e7.1429196435.git.berto@igalia.com |
|---|---|
| State | New |
| Headers | show |
On 16.04.2015 17:12, Alberto Garcia wrote: > Signed-off-by: Alberto Garcia <berto@igalia.com> > --- > docs/live-block-ops.txt | 30 +++++++++++++++++++----------- > 1 file changed, 19 insertions(+), 11 deletions(-) Reviewed-by: Max Reitz <mreitz@redhat.com>
On 04/16/2015 09:12 AM, Alberto Garcia wrote: > Signed-off-by: Alberto Garcia <berto@igalia.com> > --- > 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 <eblake@redhat.com>
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] -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] The operation is implemented in QEMU through image streaming facilities. @@ -35,14 +37,20 @@ streaming operation completes it raises a QMP event. 'block_stream' copies data from the backing file(s) into the active image. When finished, it adjusts the backing file pointer. -The 'base' parameter specifies an image which data need not be streamed from. -This image will be used as the backing file for the active image when the -operation is finished. +The 'base' parameter specifies an image which data need not be +streamed from. This image will be used as the backing file for the +destination image when the operation is finished. + +In the first example above, the command would be: + +(qemu) block_stream virtio0 file-A.img -In the example above, the command would be: +In order to specify a destination image different from the active +(rightmost) one we can use its (previously set) node name instead. -(qemu) block_stream virtio0 A +In the second example above, the command would be: +(qemu) block_stream node-D file-B.img Live block copy ===============
Signed-off-by: Alberto Garcia <berto@igalia.com> --- docs/live-block-ops.txt | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-)