On 04/04/2018 15:49, Fam Zheng wrote: >> I posted concerns about the bdrv_co_map_range() interface. It would be >> safer to only have a copy_range() interface without exposing how data is >> mapped outside the driver where race conditions can occur and the format >> driver no longer has full control over file layout. > It's a good point, but I couldn't think of a way to implement copy_range > between > two format drivers: both of them need to recurse down to their bs->file and > what > we eventually want is a copy_file_range() on two fds (or an iscsi equivalent): > > src[qcow2] -> dst[raw] > | | > v v > src[file] -> dst[file] > | | > v v > fd1 -> fd2 > copy_file_range > > Maybe we should add BlockDriver.bdrv_co_map_range_{prepare,commit,abort} and > call them from bdrv_co_copy_range(). This way the code path works pretty much > the same way to .bdrv_co_preadv/pwritev.
Or you could have bdrv_co_copy_range verify the mapping and return -EAGAIN if it is not valid anymore? (Then bdrv_co_map_range should fill in a BlockDriverMapping struct, or something like that). Paolo