On Fri, Jan 29, 2016 at 02:26:51PM +0100, Michal Privoznik wrote:
** NOT TO BE MERGED UPSTREAM **This is merely an RFC. What's the problem? We have APIs for transferring disk images from/to host. Problem is, disk images can be sparse files. Our code is, however, unaware of that fact so if for instance the disk is one big hole of 8GB all those bytes have to: a) be read b) come through our event loop. This is obviously very inefficient way. How to deal with it? The way I propose (and this is actually what I like you to comment on) is to invent set of new API. We need to make read from and write to a stream sparseness aware. The new APIs are as follows: int virStreamSendOffset(virStreamPtr stream, unsigned long long offset, const char *data, size_t nbytes); int virStreamRecvOffset(virStreamPtr stream, unsigned long long *offset, char *data, size_t nbytes); The SendOffset() is fairly simple. It is given an offset to write @data from so it basically lseek() to @offset and write() data. The RecvOffset() has slightly complicated design - it has to be aware of the fact that @offset it is required to read from fall into a hole. If that's the case it sets @offset to new location where data starts. Are there other ways possible? Sure! If you have any specific in mind I am happy to discuss it. For instance one idea I've heard (from Martin) was instead of SendOffset() and RecvOffset() we may just invent our variant of lseek().
Also StreamRecv (and send) that would return the number of bytes read (skipped) in a parameter and the return value itself would be an enum saying whether that read ended up in a hole or end of file or it was success. One more idea was to have a a way of registering a callback that would be called with offsets and buffers and the holes would be skipped that way.
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
