On Wed, Apr 28, 2010 at 04:19:11PM +0200, Daniel Veillard wrote:
> On Wed, Apr 28, 2010 at 01:54:45PM +0100, Daniel P. Berrange wrote:
> > Some applications need to be able to query a guest's disk info,
> > even for paths not managed by the storage pool APIs. This adds
> > a very simple API to get this information, modelled on the
> > virStorageVolGetInfo API, but with an extra field 'physical'.
> > Normally 'physical' and 'allocation' will be identical, but
> > in the case of a qcow2-like file stored inside a block device
> > 'physical' will give the block device size, while 'allocation'
> > will give the qcow2 image size
> [....]
> > +
> > +/** virDomainBlockInfo:
> > + *
> > + * This struct provides information about the size of a block device backing store
> > + *
> > + * Examples:
> > + *
> > + * - Fully allocated raw file in filesystem:
> > + * * capacity, allocation, physical: All the same
> > + *
> > + * - Sparse raw file in filesystem:
> > + * * capacity: logical size of the file
> > + * * allocation, physical: number of blocks allocated to file
> > + *
> > + * - qcow2 file in filesystem
> > + * * capacity: logical size from qcow2 header
> > + * * allocation, physical: logical size of the file / highest qcow extent (identical)
> > + *
> > + * - qcow2 file in a block device
> > + * * capacity: logical size from qcow2 header
> > + * * allocation: highest qcow extent written
> > + * * physical: size of the block device container
> > + */
>
> Argh, forgot that in my previous review, we need to explicitely tell
> the size units, I expect bytes but we're unsing kB in some places
> so...
>
> > +typedef struct _virDomainBlockInfo virDomainBlockInfo;
> > +typedef virDomainBlockInfo *virDomainBlockInfoPtr;
> > +struct _virDomainBlockInfo {
> > + unsigned long long capacity; /* logical size of the block device backing image */
> > + unsigned long long allocation; /* allocated extent of the block device backing image */
> > + unsigned long long physical; /* physical size of the container of the backing image */
> > +};
>
> s/size/size in bytes/g
Yes, they're all bytes.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list