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 <[email protected]
<mailto:[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]
<mailto:[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
--
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10
<tel:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded
