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
