[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu-img measure

From: Arik Hadas
Subject: Re: qemu-img measure
Date: Mon, 27 Jul 2020 01:08:48 +0300

On Fri, Jul 24, 2020 at 5:00 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
On Thu, Jul 23, 2020 at 07:31:13PM +0300, Nir Soffer wrote:
> On Thu, Jul 23, 2020 at 6:12 PM Arik Hadas <ahadas@redhat.com> wrote:
> > [root@lion01 8c98c94d-bc14-4e24-b89c-4d96c820056d]# qemu-img measure -O qcow2 /tmp/arik.qcow2
> > required size: 9359720448
> > fully allocated size: 16108814336
> Now we have qcow2 image, so we don't depend on the file system capabilities.
> This is the advantage of using advanced file format.
> > shouldn't the 'measure' command be a bit smarter than that? :)
> I think it cannot be smarter, but maybe qemu folks have a better answer.

qemu-img measure checks that allocation status of blocks. As Nir said,
if the file system (older NFS versions) doesn't support that then it
doesn't know about zero blocks.

It would be possible to add a slow loop that reads the entire input
image but I'm not sure how useful it would be to read many gigabytes of
data from the disk. The process would be slow and degrade performance of
VMs by consuming I/O bandwidth.

Not sure about the general case either but specifically for exporting VMs to OVAs it can be useful.
Yes, it may be slow and degrade the performance of the VM for longer time (the next step when exporting a running VM is copying the measured disk(s) so the latter may happen anyway) but, arguably, still better than the alternatives of allocating (potentially) the virtual size of the disk within the OVA or copying the image twice.
Maybe we can add an optional parameter that makes qemu-img measure to fall back to that slow loop when the blocks' allocation status is not provided by the file system?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]