Re: Re: Problems KVM-84

Uri Lublin
2009-03-11T22:59:52Z

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.