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).