[Libguestfs] [PREVIEW ONLY] Refactor data transfer code

[Matthew Booth]

On 21/09/10 20:12, Richard W.M. Jones wrote:
>
> This patch is not using hread/hwrite?

No. That will be required for changing formats, but not for a straight copy.

> Anyway I'd be interested in whether you can do all you wanted from
> hread/hwrite/hseek/etc using the proposed upload-offset API that I
> posted here:
>
> http://www.redhat.com/archives/libguestfs/2010-September/msg00026.html
> http://www.redhat.com/archives/libguestfs/2010-September/msg00027.html

No, because the API requires passing in a file, which I don't have. The 
source of the data is a stream, which may come from an HTTPS connection, 
cat over ssh, or a local file. When I implement format changing, it will 
also come from a libguestfs handle (I'll copy data between 2 open handles).

> I tried implementing the 'hexedit' command using both APIs and using
> upload-offset the code was considerably simpler.  Of course, while
> that's interesting, it is not necessarily comparable to what virt-v2v
> needs to do.
>
> One possible advantage for upload-offset is that you can stream data
> in without knowing or specifying in advance how much data you will
> stream in.  Also the amount you can stream in has no protocol limits.
> So I imagine that you could stream data, while looking for
> zero-blocks, and when you reach a block of zeroes you would finish the
> current upload-offset call and start a new one after the block of
> zeroes finishes.  Since this is all done at a byte level, there is no
> need for reads from the source to be in blocks, or to be aligned, or
> to have any maximum size.
>
> On a related topic: In the above email I claimed that because these
> use FileIn/FileOut, they should be more efficient.  In fact once I
> measured it, I found there was not a lot of difference.  But I'm still
> looking at why that is, because I'm fairly sure that FileIn/FileOut
> _ought_ to be more efficient than making lots of discrete
> non-pipelined API calls.

I suspect that virtio-serial is just so fast compared to writing to disk 
it makes next next to no difference.

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490