[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] [RFC PATCH 0/8] qemu-img convert with copy
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [Qemu-block] [RFC PATCH 0/8] qemu-img convert with copy offloading |
Date: |
Wed, 4 Apr 2018 21:49:23 +0800 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
On Wed, 04/04 14:23, Stefan Hajnoczi wrote:
> On Thu, Mar 29, 2018 at 07:09:06PM +0800, Fam Zheng wrote:
> > [Posting a preview RFC for the general idea discussion and internal API
> > review.
> > Libiscsi support is being worked on in the meantime.]
> >
> > This series introduces block layer API for copy offloading and makes use of
> > it
> > in qemu-img convert.
> >
> > For now we implemented the operation in local file protocol with
> > copy_file_range(2). Besides that it's possible to add similar to iscsi, nfs
> > and potentially more.
> >
> > As far as its usage goes, in addition to qemu-img convert, we can emulate
> > offloading in scsi-disk (EXTENDED COPY), and do similar to drive-mirror.
> >
> > The new bdrv_co_map_range can also be an alternative way to implement format
> > drivers in the future, once we make block/io.c use it in preadv/pwritev
> > paths.
>
> 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.
Fam