On Wed, May 28, 2025 at 01:39:25PM +0200, Markus Armbruster wrote:
> Eric Blake <ebl...@redhat.com> writes:
>
> > Prove that blockdev-mirror can now result in sparse raw destination
> > files, regardless of whether the source is raw or qcow2. By making
> > this a separate test, it was possible to test effects of individual
> > patches for the various pieces that all have to work together for a
> > sparse mirror to be successful.
> >
> Fails for me:
>
> TAP version 13
> # QEMU -- "/work/armbru/qemu/bld/qemu-system-x86_64" -nodefaults
> -display none -accel qtest
> # QEMU_IMG -- "/work/armbru/qemu/bld/qemu-img"
> # QEMU_IO -- "/work/armbru/qemu/bld/qemu-io" --cache writeback
> --aio threads -f qcow2
> # QEMU_NBD -- "/work/armbru/qemu/bld/qemu-nbd"
> # IMGFMT -- qcow2
> # IMGPROTO -- file
> # PLATFORM -- Linux/x86_64 dusky 6.12.7-200.fc41.x86_64
> # TEST_DIR -- /work/armbru/qemu/bld-x86/scratch
Which filesystem is TEST_DIR on?
> # SOCK_DIR -- /tmp/qemu-iotests-nqettsyq
> # GDB_OPTIONS --
> # VALGRIND_QEMU --
> # PRINT_QEMU_OUTPUT --
> #
> 1..1
> # running qcow2 mirror-sparse
> not ok qcow2 mirror-sparse
> --- /work/armbru/qemu/tests/qemu-iotests/tests/mirror-sparse.out
> +++
> /work/armbru/qemu/bld-x86/scratch/qcow2-file-mirror-sparse/mirror-sparse.out.bad
> @@ -140,7 +140,7 @@
> {"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP},
> "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "job2"}}
> {"return": {}}
> Images are identical.
> -Destination is sparse; expected sparse
> +Destination is unknown; expected sparse
> > Looks like the same failure Fiona reported; does this fix it?
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2025-05/msg05567.html
>
> It does not.
Since my patch for Fiona is not working for you, I will tweak it
slightly to output the actual du output (in addition to "unknown") for
the cases where the size is neither -lt 3M or -gt 19M. The test is
dealing with a 20M image containing 2M of data, so du reporting
something in between 3 and 19 is unexpected. Could it be the result
of du reporting smaller numbers on a compressed filesystem? But even
then, my followup series was trying to filter out any filesystem where
-o preallocation=full of 5M results in a du report of < 4M on the
grounds that it would catch compression artifacts as rendering the
test unreliable.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
