|
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 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?
Stefan
--
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
|