• Max Reitz's avatar
    block/mirror: Fix target backing BDS · 274fccee
    Max Reitz authored
    Currently, we are trying to move the backing BDS from the source to the
    target in bdrv_replace_in_backing_chain() which is called from
    mirror_exit(). However, mirror_complete() already tries to open the
    target's backing chain with a call to bdrv_open_backing_file().
    
    First, we should only set the target's backing BDS once. Second, the
    mirroring block job has a better idea of what to set it to than the
    generic code in bdrv_replace_in_backing_chain() (in fact, the latter's
    conditions on when to move the backing BDS from source to target are not
    really correct).
    
    Therefore, remove that code from bdrv_replace_in_backing_chain() and
    leave it to mirror_complete().
    
    Depending on what kind of mirroring is performed, we furthermore want to
    use different strategies to open the target's backing chain:
    
    - If blockdev-mirror is used, we can assume the user made sure that the
      target already has the correct backing chain. In particular, we should
      not try to open a backing file if the target does not have any yet.
    
    - If drive-mirror with mode=absolute-paths is used, we can and should
      reuse the already existing chain of nodes that the source BDS is in.
      In case of sync=full, no backing BDS is required; with sync=top, we
      just link the source's backing BDS to the target, and with sync=none,
      we use the source BDS as the target's backing BDS.
      We should not try to open these backing files anew because this would
      lead to two BDSs existing per physical file in the backing chain, and
      we would like to avoid such concurrent access.
    
    - If drive-mirror with mode=existing is used, we have to use the
      information provided in the physical image file which means opening
      the target's backing chain completely anew, just as it has been done
      already.
      If the target's backing chain shares images with the source, this may
      lead to multiple BDSs per physical image file. But since we cannot
      reliably ascertain this case, there is nothing we can do about it.
    Signed-off-by: 's avatarMax Reitz <mreitz@redhat.com>
    Message-id: 20160610185750.30956-3-mreitz@redhat.com
    Reviewed-by: 's avatarKevin Wolf <kwolf@redhat.com>
    Reviewed-by: 's avatarFam Zheng <famz@redhat.com>
    Signed-off-by: 's avatarMax Reitz <mreitz@redhat.com>
    274fccee
block.c 113 KB