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