On 04/02/2015 07:28 AM, Alberto Garcia wrote:
> Hi,
> 
> I'm interested in adding the possibility to mirror an intermediate
> node in a disk image chain, but I would like to have some feedback
> before sending any patches.
> 
> The goal would be to convert this:
> 
>    [A] -> [B] -> [C] -> [D]
> 
> into this:
> 
>    [A] -> [B] -> [X] -> [D]
> 
> where [D] is the active image and [X] would be a copy of [C]. The
> latter would be unlinked from the chain.

Seems useful, if for no other reason than to be another tool in the
arsenal of low-level manipulations that can be strung together for cool
high-level operations.

> 
> A use case would be to move disk images across different storage
> backends.
> 
> My idea is to extend the drive-mirror command. Similar to what we
> discussed in the case of the intermediate block streaming, I can reuse
> the 'device' parameter to refer to a node name. So the API doesn't
> need any changes other than the extended semantics for this parameter.
> 
> One difference with the current functionality is that once the block
> job is completed, the node above the mirrored one would have to change
> its backing image to point to the new one. One solution is to iterate
> over all devices (bdrv_next()) and check which ones are connected
> directly or indirectly to the mirrored node (bdrv_find_overlay()).
> 
> drive-mirror has three different sync modes: top, full and none. This
> would be the chain from the example using each one of these modes:
> 
>   top:
> 
>      [A] -> [B] -> [X] -> [D]

That is, X becomes the mirror of C, and then a later command lets us
rebase D onto X (since we know the guest-visible contents accessible
from X and C are identical).

> 
>   full:
> 
>      [X] -> [D]

That is, X becomes the mirror of the full chain A through C, and then a
later command lets us rebase D onto X (since we know the guest-visible
contents accessible from X and C are identical).

> 
>   none:
> 
>      [A] -> [B] -> [C] -> [X] -> [D]

That is, X becomes a new file that tracks changes made since a point in
time which are also going into C; and if we desire we can issue a later
command to rebase D onto X (since we know the guest-visible contents
accessible from X and C are identical at that time), and even later
start cleaning up C (we could use dirty bitmaps to see what got moved
into X to clean those sectors out of C and reduce its size)

> 
> My understanding is that in the 'sync=full' case, [A] and [B] would
> also need to be blocked during the operation since they are going to
> disappear from the chain.
> 
> I have some code and in principle everything seems to be working fine,
> but I'd like to test it a bit more.
> 
> What's anyway your opinion about this proposal?

Certainly seems like something worth having.  The devil may be in the
details, but we can get there when you post proposed patches.

> 
> Thanks,
> 
> Berto
> 
> 
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org