On Fri, Jul 24, 2020 at 5:00 PM Stefan Hajnoczi <[email protected]> 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 <[email protected]> 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? > > Stefan >
