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