On 12/16/2014 03:16 AM, Daniel P. Berrange wrote: > On Mon, Dec 15, 2014 at 05:29:14PM -0700, Eric Blake wrote: >> I'm really struggling with how to interpret the virDomainBlockInfo >> struct, and think that we may want to consider the current behavior >> buggy and offer improved behavior going forward. >> >> >> I interpret this to mean that 'capacity' is the size that the guest >> sees, that 'allocation' is how much host space is required to represent >> that to the guest, and 'physical' is the size of the container on the host. >> >> >> Can anyone give a reason why changing semantics of 'physical' and >> 'allocation' as mentioned above would negatively break backwards >> compatibility, rather than being considered a bug fix? > > You don't mention the equivalent virStorageVolInfo struct for the > storage drivers above. This has a capacity & allocation attribute. Right now, 'capacity' for virStorageVolInfo is always the size the guest will see (matching how we use 'capacity for virDomainBlockInfo), and 'allocation' of a qcow2 file is probably closer to what I'm using 'physical' for (that is, it appears to be the file size). I guess where I'd like to go with this is expand virStorageVolInfo to add 'physical', and then have the same distinction (being able to tell both how much space the host file would claim if fully allocated, and how much space it is actually using thanks to holes). I guess I have more patches to write to make things consistent before the release at the end of January! > > So I think it is important that we keep capacity & allocation having > the same meanings across both. I agree. One of the problems with qcow2 images on block devices is that qemu-img does NOT give us highest-extent-written information (what I'm calling 'allocation'), so on a storage pool looking at LVM partitions that contain qcow2-formatted images, the storage code is currently reporting 'allocation' as the block device size, but that's more what I term 'physical'; on the other hand, until qemu is patched to give us highest-extent-written details, 'physical' and 'allocation' will be the same for such images. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list