My hunch is that we're handling zero regions incorrectly and we might be
skipping data regions we ought to be copying.
...I'm looking at the `image2.qemu` file you've uploaded and it's empty!
we didn't copy *anything* from your source file.
Try converting with '-S 0` to disable sparse protection and see if that
might help.
'-S' indicates the consecutive number of bytes (defaults to 4k) that must
contain only zeros for qemu-img to create a sparse image during
conversion. If the number of bytes is 0, the source will not be scanned
for
unallocated or zero sectors, and the destination image will always be
fully allocated
If that helps, I'd take a look at img_convert in qemu-img.c ...
convert_iteration_sectors looks relevant, it appears to help us know
which sectors to copy when called by convert_co_do_copy.
Tracing around "convert_co_read" in the same function might also help us
to know which portions of the image we're even deciding to read; and we
could probably track backwards from there to figure out which
condition(s) are disqualifying us if we're deciding not to copy data.
My current hunch is that bdrv_block_status[_above] is returning
something wrong when backed by APFS.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1776920
Title:
qemu-img convert on Mac OSX creates corrupt images
Status in QEMU:
New
Bug description:
An image created by qemu-img create, then modified by another program
is converted to bad/corrupt image when using convert sub command on
Mac OSX. The same convert works on Linux. The version of qemu-img is
2.12.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1776920/+subscriptions
