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