Re: [Qemu-devel] [PATCH] qemu-img: implement copy offload (-C) for dd

[Sergio Lopez]

On Thu, Feb 21, 2019 at 12:08:12PM -0600, Eric Blake wrote:
> On 2/21/19 11:37 AM, Sergio Lopez wrote:
> > This parameter is analogous to convert's "-C", making use of
> > bdrv_co_copy_range().
> 
> The last time I tried to patch 'qemu-img dd', it was pointed out that it
> already has several bugs (where it is not on feature-parity with real
> dd), and that we REALLY want to make it a syntactic sugar wrapper around
> 'qemu-img convert', rather than duplicating code (which means that
> qemu-img convert needs to make it easier to do arbitrary offsets and
> subsets - although to some extent you can already do that with
> --image-opts and appropriate raw driver wrappers).
> 
> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg02618.html

Interesting, I wasn't aware of that conversation. It might a little late
to go again through it, but while I don't a strong opinion about it, I
do have some reservations about the idea of making 'dd' a frontend for
'convert'.

While I do see the functional similarity of both commands, to me they
are quite different at a semantical level. For 'convert', I do expect it
to do "the right thing" and use the optimal settings (i.e. choosing the
best transfer size) by default, while 'dd' is more of "do whatever the
user told you to do no matter how wrong it is".

Due to this differences, I think turning 'convert' code into something
able to deal with 'dd' semantics would imply adding a considerable
number of conditionals, possibly making it harder to maintain than
keeping it separate.

Sergio (slp).