Re: [libvirt] [PATCH 1/6] Add new API virDomainStreamDisk[Info] to header and drivers

On 04/11/2011 04:45 PM, Daniel P. Berrange wrote: >On Fri, Apr 08, 2011 at 02:26:48PM -0500, Anthony Liguori wrote: >>On 04/08/2011 11:02 AM, Stefan Hajnoczi wrote: >>>On Fri, Apr 8, 2011 at 2:31 PM, Daniel P. Berrange<berrange(a)redhat.com> wrote: >>> >>>I have CCed Anthony and Kevin. Anthony drove the QED image streaming >>>and Kevin will probably be interested in the idea of allocating raw >>>images as a background activity while QEMU runs. >>> >>>> /* >>>> * @path: fully qualified filename of the virtual disk >>>> * @nregions: filled in the number of @region structs >>>> * @regions: filled with a list of allocated regions >>>> * >>>> * Query the extents of allocated regions within the >>>> * virtual disk file. The offsets in the list of regions >>>> * are not guarenteed to be sorted in any explicit order. >>>> */ >>>> int virDomainBlockGetAllocationMap(virDomainPtr dom, >>>> const char *path, >>>> unsigned int *nregions, >>>> virDomainBlockRegionPtr *regions); >>>QEMU can provide this with its existing .bdrv_is_allocated() function. >>> Kevin, do you have any thoughts on whether this API will work well? >>I think the trouble with this API proposal is that it's overloading >>concepts. >> >>Sparse is not the same thing as CoW to a backing file. >I don't like to use the term "sparse", since that implies a specific disk >format (raw file with holes). Rather I use the term 'thin provisioned' >to refer to any disk format, where the not all physical sectors have >yet been allocated. A thin-provisioned disk, can trivially be thought >of as a disk, with a backing file whose sectors are all filled with >zeros. It's not so black and white today. Imagine that you had a qcow2 file, and you "streamed" it such that it was no longer "thin provisioned", as soon as the guest starts issuing trim/discards, QEMU could conceivably start defragmenting the image and truncating resulting in a sparse file. The only time the concept of "fully allocated" really makes sense is for a raw image on a simple file system. Once you start dealing with things like btrfs and deduplication, and of those useful guarantees are thrown out the window.

I think the real question is, why do you care about what physical sectors reside where? What problem are you trying to solve?

>>For instance, when you expose streaming, the result is still a >>sparse file. So you'd have a rather curious API where you called to >>"allocate" a region in the file which resulted in having a sparse >>file which you then called again to make it non sparse. But AFAICT, >>the API doesn't really tell you these details. >Copy-on-read streaming does not imply that the result is still >thin-provisioned. That is a policy decision by the management >application. I think your notion of thin-provision doesn't quite map to how things work today. Unless you're in a very constrained environment, you're always thin provisioned.