Re: [Qemu-devel] [PATCH 2/2] qemu-img: Add dd seek= option

[Eric Blake <eblake@redhat.com>]

On 08/15/2018 09:49 PM, Max Reitz wrote:

>>> In my opinion, we do not want feature parity with dd.  What we do want
>>> is feature parity with convert.
>>
>> Well, convert is lacking a way to specify a subset of one file to move
>> to a (possibly different) subset of the other.  I'm fine if we want to
>> enhance convert to do the things that right now require a dd-alike
>> interface (namely, limiting the copying to less than the full file, and
>> choosing the offset at which to start [before this patch] or write to
>> [with this patch]).
> 
> Yes, I would want that.
> 
>> If convert were more powerful, I'd be fine dropping 'qemu-img dd' after
>> a proper deprecation period.
> 
> Technically it has those features already, with the raw block driver's
> offset and size parameters.

Perhaps so, but it will be an interesting exercise in rewriting the 
shorthand nbd://host:port/export into the proper longhand driver syntax.


>>
>> Because of performance: qemu-nbd + Linux nbd device + real dd is one
>> more layer of data copying (each write() from dd goes to kernel, then is
>> sent to qemu-nbd in userspace as a socket message before being sent back
>> to the kernel to actually write() to the final destination) compared to
>> just doing it all in one process (write() lands in the final destination
>> with no further user space bouncing).  And because the additional steps
>> to set it up are awkward (see my other email where I rant about losing
>> the better part of today to realizing that 'dd ...; qemu-nbd -d
>> /dev/nbd1' loses data if you omit conv=fdatasync).
> 
> I can see the sync problems, but is the performance really that much worse?

When you don't have sparse file support, reading or writing large blocks 
of zeroes really is worse over /dev/nbd* than over a server/client pair 
that know how to do it efficiently.  But for non-sparse data, I don't 
know if a benchmark would be able to consistently note a difference 
(might be a fun benchmark for someone to try, but not high on my current 
to-do list).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org