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

[Uri Lublin]

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 <address@hidden>
> > >   Signed-off-by: Anthony Liguori <address@hidden>
> > >
> > > 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.