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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

On 2018-08-16 04:57, Eric Blake wrote:
> 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.

Don't dare me! :-)

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

Hm.  Yeah.  Well, for me, it remains that it would be better to have a
good way of exposing image contents to all of the rest of the system and
all of the nice tools there already are instead of re-implementing them
in qemu.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]