Re: [Qemu-devel] Re: Problems KVM-84

[Uri Lublin <uril@redhat.com>]

Jamie Lokier wrote:
> Anthony Liguori wrote:
>>>   block-qcow2: keep highest allocated byte (Uri Lublin)
>>>     We want to know the highest written offset for qcow2 images.
>>>   This gives a pretty good (and easy to calculate) estimation to how
>>>   much more allocation can be done for the block device.
>>>     It can be usefull for allocating more diskspace for that image
>>>   (if possible, e.g. lvm) before we run out-of-disk-space
>>>     Signed-off-by: Uri Lublin <uril@redhat.com>
>>>   Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>>>
>>> Scanning the file at startup is slow.  We need to find a better way.
>> Any quick ideas?  Seems like this is broken by design.  Unless we can 
>> find a quick fix, I'm going to revert this in the stable tree.
> 
> I still don't understand the point in that feature.
> 
> You have the size of the qcow2 file (how much data is used), and the
> size of the image it's representing (how much it could expand to).
> 
> What does the highest written offset help you anticipate?
You assume there is a file system installed. If I want to use e.g. LVM's logical 
volume, I can not tell the size of the qcow2 image. I want to be able to set a 
watermark and handle out-of-disk-space before it actually happens.

> 
> Many guest filesystems write data all over the block device, not
> concentrated at the start.  (E.g. ext2/3/4 and it's block groups).
qcow2 allocates disk space regardless of the guest write offset.
And if it happen that the image is sparse (or fragmented), num_free_bytes can 
tell us that.

Regards,
     Uri.