[Top][All Lists]

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

Re: qemu-img measure

From: Jakob Bohm
Subject: Re: qemu-img measure
Date: Tue, 28 Jul 2020 22:30:47 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:4.6) Goanna/20200607 Interlink/52.9.7463

Proposed alternative implementation techniques:

A. Check if the block count returned by stat is less than what the apparent file size (elsewhere in the stat structure) suggests.

B. When converting from a full-size (or presumed full-size) raw image to an internally sparse format such as qcow2, do zero block detection on the fly as the blocks are copied, then write the block-absent information to the output metadata after copying the data and omitting the zero blocks.  This would only do one pass over the data, and would get the result right if something is writing to the raw image during conversion.

On 2020-07-27 00:08, Arik Hadas wrote:

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?


Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

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