On 05/12/2014 05:11 AM, Kevin Wolf wrote:

>> The next patches will convert some users of bdrv_getlength() to
>> bdrv_nb_sectors().
>>
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> 
> Is this really the right direction to move?
> 
> Generally I think we should be trying to move away from those arbitrary
> units of 512 bytes (that are called sectors for some reason, but aren't
> really related to either guest or host sector sizes), and towards
> interfaces that use byte granularity.
> 
> So I would rather see bs->total_sectors becoming bs->total_bytes than
> adding a new sector-based function.

I tend to agree that storing rounded information is the wrong thing to
do.  The qcow2 format stores the guest size in bytes, so it is
technically possible to have a file where the last sector is only a
partial sector.  However, because the current implementation rounds to
sectors (and in some cases, rounds in the wrong direction), we have
situations like:

$ qemu-img create -f qcow2 img 1234
Formatting 'img', fmt=qcow2 size=1234 encryption=off cluster_size=65536
lazy_refcounts=off
$ qemu-img info img
image: img
file format: qcow2
virtual size: 1.0K (1024 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false

where I lost 210 bytes of what the guest was supposed to be able to
access.  Consistently tracking bdrv length in bytes, and rounding up to
sectors when needed, seems like it will be better than pre-rounding to
sectors and possibly truncating the user image.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org