[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PREVIEW ONLY] Refactor data transfer code



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]