Il 20/08/2013 09:08, Fam Zheng ha scritto: > On Tue, 08/20 07:51, Alex Bligh wrote: >> >> On 20 Aug 2013, at 02:42, Fam Zheng wrote: >> >>> OK, thanks for explaination. That sounds a valid use case for >>> streamOptimized. However I am afraid QEMU and its users benefit not much >>> from this feature anyway, because it's moving a VM away to VMware, :) >>> that might be the reason it's not there yet, and I don't know about any >>> plan to do it in the near future. >> >> Well, given it is an open source project, the more interoperability >> the better. Even if it just means users need not worry about lock >> in to faster hypervisors ... Being more serious, qemu-img is >> part of the project too. >> >>> But if someone sends patches for this, I think it is possible to get in. >> >> I guessed "send code" might be the answer :-) >> >> What I'm not sure of is whether the streaming format has to be written >> sequentially from as opposed to random writes. I believe the way >> qemu-img convert works, one can't guarantee the writes are >> sequential. >> > The order of sectors doesn't matter, but granularity should be aligned > to, as the data is compressed cluster by cluster. And no overwrite, of > course. The challenge may be that header comes at the end of file > (well, called footer), which is not decided at create time.
It doesn't look too different from what "qemu-img convert -c" does, except that you need to use the right "-o" incantation to specify the format type. Paolo
