[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [RFC PATCH 0/8] qemu-img convert with copy offloading
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-block] [RFC PATCH 0/8] qemu-img convert with copy offloading |
Date: |
Fri, 6 Apr 2018 13:41:53 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
On 05/04/2018 14:55, Stefan Hajnoczi wrote:
> bdrv_copy_file_range() will invoke bdrv_co_copy_file_range_src() on
> src[qcow2]. The qcow2 block driver will invoke
> bdrv_co_copy_file_range_src() on src[file]. The file-posix driver will
> invoke bdrv_co_copy_file_range_dst() on dst[raw]. The raw driver will
> invoke bdrv_co_copy_file_range_dst() on dst[file], which sees that
> src_bds (src[file]) is also file-posix and then goes ahead with
> copy_file_range(2).
>
> In the case where src[qcow2] is on file-posix but dst[raw] is on iSCSI,
> the iSCSI .bdrv_co_copy_file_range_dst() call fails with -ENOTSUP and
> the block layer can fall back to a traditional copy operation.
>
> With this approach src[qcow2] could take a lock or keep track of a
> serializing request struct so that other requests cannot interfere with
> the operation, and it's done in a natural way since we remain in the
> qcow2 function until the entire operation completes. There's no need
> for bookkeeping structs or callbacks.
Could there be AB-BA deadlock if the guest attempts a concurrent copy
from A to B and from B to A?
Paolo
signature.asc
Description: OpenPGP digital signature