Re: [Qemu-block] [PATCH 2/7] block: add bdrv_get_format_allocated_size format interface

[Eric Blake]

On 05/25/2017 01:19 PM, Vladimir Sementsov-Ogievskiy wrote:

> No, it will not be negative, all OK. I've mistaken. length of
> bs->file->bs will be positive anyway.
> 
> Actually, current approach is the following:
> 
> a. clusters allocated in qcow2 and after the end of bs->file: unallocated

How often do we actually end up in this situation? I know there are a
few cases where it makes sense (for example, if your image is large
enough to have L1 occupy two clusters, but the guest hasn't written
anything in the second half of the guest-visible area, then the second
cluster of the L1 table can be all zeroes - and depending on allocation
patterns, it is feasible that the L1 table can occupy the end of the
image, where the second cluster of the L1 table thus points beyond
end-of-file of the underlying image while still being a well-formed
qcow2 image).  It may also be a common transitory state in how we expand
a qcow2 image; if the expansion is interrupted in the middle, we could
easily have the refcount table saying a cluster has been allocated while
we have not yet actually written to the host file.

> b. clusters allocated in qcow2 and which are holes bs->file: allocated

This may be more common; a typical example is if we have a cluster
marked QCOW2_CLUSTER_NORMAL but which maps to a hole (and therefore
bdrv_get_block_status will report it as BDRV_BLOCK_DATA|BDRV_BLOCK_ZERO).

> 
> (a) look inconsistent with b and with commit message and other things.
> But if I just account (a) clusters, it will lead to negative size of
> unallocated and will spoil the whole stat.. Something should be
> adjusted, at least at comment/commit-message level.

Exposing the stat as a difference may not make as much sense as
reporting actual numbers (this image requires an allocation of this many
bytes to fully represent current guest- and meta-data, even if some of
the allocation is currently pointing to holes or beyond the end of the
underlying file).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature