[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] qemu-img: Add dd seek= option
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] qemu-img: Add dd seek= option |
Date: |
Thu, 16 Aug 2018 05:00:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 0/2] Improve qemu-img dd, Eric Blake, 2018/08/15
Re: [Qemu-devel] [PATCH 0/2] Improve qemu-img dd, no-reply, 2018/08/16
Re: [Qemu-devel] [PATCH 0/2] Improve qemu-img dd, no-reply, 2018/08/16
Re: [Qemu-devel] [PATCH 0/2] Improve qemu-img dd, Eric Blake, 2018/08/19