When extending the size of a short overlay over a longer backing file, the new area doesn't correctly read as zeros, but the backing file contents becomes visible. Amongst others, this affects commit block jobs in a situation like the following: base (10 GB) <- mid (5 GB) <- top (8 GB) In this case, unallocated blocks in top in the area from 5 GB to 8 GB read as zeros before the commit operation. However, commit resizes mid to 8 GB and the data will suddenly be read from base instead of reading as zero. This is a corruption bug. Reproducer: qemu-img create -f qcow2 /tmp/base.qcow2 2M qemu-img create -f qcow2 -b /tmp/base.qcow2 /tmp/mid.qcow2 1M qemu-img create -f qcow2 -b /tmp/mid.qcow2 /tmp/top.qcow2 2M qemu-io -c 'write -P1 0 2M' /tmp/base.qcow2 qemu-io -c 'read -P0 1M 1M' /tmp/top.qcow2 qemu-img commit /tmp/top.qcow2 qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2 Actual result: [...] Image committed. Pattern verification failed at offset 1048576, 1048576 bytes read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (3.291 GiB/sec and 3370.1125 ops/sec) Expected result: No "Pattern verification failed" message.
Reproduced this issue as below. Tested with: qemu-kvm-4.2.0-1.module+el8.2.0+4793+b09dd2fb kernel-4.18.0-153.el8 Steps: 1. Create images. # qemu-img create -f qcow2 /tmp/base.qcow2 2M # qemu-img create -f qcow2 -b /tmp/base.qcow2 /tmp/mid.qcow2 1M # qemu-img create -f qcow2 -b /tmp/mid.qcow2 /tmp/top.qcow2 2M 2. Write data to the base image. # qemu-io -c 'write -P1 0 2M' /tmp/base.qcow2 3. Check the data info of top image. # qemu-io -c 'read -P0 1M 1M' /tmp/top.qcow2 read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (10.087 GiB/sec and 10329.1913 ops/sec) 4. Commit top image. # qemu-img commit /tmp/top.qcow2 5. Check the data info mid image # qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2 Pattern verification failed at offset 1048576, 1048576 bytes read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (1.720 GiB/sec and 1761.0626 ops/sec) # qemu-io -c 'read -P1 1M 1M' /tmp/mid.qcow2 read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (1.556 GiB/sec and 1593.0873 ops/sec) Result. As above. After step5, the read data should be "0" as step3 not "1".
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Reproduced it with qemu-kvm-4.2.0-23.module+el8.2.1+6917+927fbb44 After step 5: # qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2 Pattern verification failed at offset 1048576, 1048576 bytes read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (1.822 GiB/sec and 1866.0302 ops/sec) # qemu-io -c 'read -P1 1M 1M' /tmp/mid.qcow2 read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (1.532 GiB/sec and 1569.1000 ops/sec) Retested it with qemu-kvm-4.2.0-25.module+el8.2.1+6972+1d0c04b6, it works well. So set bug status to VERIFIED. Versions: kernel-4.18.0-193.1.2.el8_2.x86_64 qemu-kvm-4.2.0-25.module+el8.2.1+6972+1d0c04b6 Steps: 1. Create images. # qemu-img create -f qcow2 /tmp/base.qcow2 2M # qemu-img create -f qcow2 -b /tmp/base.qcow2 /tmp/mid.qcow2 1M # qemu-img create -f qcow2 -b /tmp/mid.qcow2 /tmp/top.qcow2 2M 2. Write data to the base image. # qemu-io -c 'write -P1 0 2M' /tmp/base.qcow2 wrote 2097152/2097152 bytes at offset 0 2 MiB, 1 ops; 00.06 sec (33.988 MiB/sec and 16.9939 ops/sec) 3. Check the data info of top image. # qemu-io -c 'read -P0 1M 1M' /tmp/top.qcow2 read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (9.345 GiB/sec and 9569.5611 ops/sec) 4. Commit top image. # qemu-img commit /tmp/top.qcow2 Image committed. 5. Check the data info mid image # qemu-io -c 'read -P0 1M 1M' /tmp/mid.qcow2 read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (5.160 GiB/sec and 5283.8483 ops/sec) # qemu-io -c 'read -P1 1M 1M' /tmp/mid.qcow2 Pattern verification failed at offset 1048576, 1048576 bytes read 1048576/1048576 bytes at offset 1048576 1 MiB, 1 ops; 00.00 sec (4.842 GiB/sec and 4958.4236 ops/sec) Result. As above. After step5, the read data is "0" as step3 not "1".
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3172