Bug 1136382
| Summary: | block: Mirroring to raw block device doesn't zero out unused blocks | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jeff Cody <jcody> |
| Component: | qemu-kvm-rhev | Assignee: | Jeff Cody <jcody> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | eblake, hhuang, huding, juzhang, kwolf, michen, mrezanin, pezhang, rbalakri, tlavigne, virt-bugs, virt-maint, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-rhev-2.3.0-28.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 971297 | Environment: | |
| Last Closed: | 2015-12-04 16:18:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 971297 | ||
| Bug Blocks: | 971312 | ||
Fix included in qemu-kvm-rhev-2.3.0-28.el7 Reproduced: Kernel:3.10.0-322.el7.x86_64 qemu-kvm-rhev:qemu-kvm-rhev-2.3.0-27.el7.x86_64 Steps: 1. create an empty qcow2 file # qemu-img create -f qcow2 /tmp/test.qcow2 64M 2. dd a file and association it with a loop device # dd if=/dev/urandom of=/tmp/test.raw bs=1M count=64 # losetup /dev/loop2 /tmp/test.raw # chmod 666 /dev/loop2 3. boot guest and do mirror job to the loop device # /usr/libexec/qemu-kvm \ -drive file=/tmp/test.qcow2,format=qcow2,if=none,id=drive-virtio-blk1,werror=stop,rerror=stop \ -device virtio-blk-pci,drive=drive-virtio-blk1,id=virtio-blk1 \ -monitor stdio (qemu) drive_mirror drive-virtio-blk1 /dev/loop2 raw (qemu) block_job_complete drive-virtio-blk1 (qemu) quit 4. check the loop device # sudo hexdump -n 512 /dev/loop2 0000000 0ec0 50e0 c6f0 e7cb 7548 eb08 cfae b858 0000010 7045 c6e5 5b48 b0ec 487e c82f fa13 2502 0000020 2d27 8abe d132 5315 fb42 fe19 8866 c3a7 0000030 f524 d405 8c78 9609 8e4a e76a 3793 17fc 0000040 64b0 ba01 ae56 3ded daac ef0e 32fe 8a9e 0000050 60ed 23c2 644c 0805 6572 a25a 8911 99a3 0000060 ab1a 5710 f1ef e344 463b b33a a721 42c8 0000070 c5d2 f75f 00ae 2e09 164f 0598 8585 85d5 0000080 e6c8 2e24 29fa 438a ca9c 76cb e7a0 9bab 0000090 50c4 cc51 17c9 b6fd 93bc 4c98 59ff 54c5 00000a0 b615 93b3 067e 0e83 a78e a6f1 41c1 8123 00000b0 39f5 ebb2 7ee0 2216 8bb4 5a09 e8e5 2089 00000c0 2fed 70bc 7663 51c8 88d9 a16a bd71 1b2c 00000d0 0a5a d25b 77ba 580e 7838 1cf0 294c eed5 00000e0 a60d 8b78 25c8 1ebf 11c9 e3f0 6004 5800 00000f0 e383 5cab c96e 1b7a 1f23 6f71 e63a 5e64 0000100 e580 2f1e 3508 1f47 7747 36b0 2e82 9bb3 0000110 0c1a df97 9420 0998 9d3d 859d 8782 75dd 0000120 85d8 ac06 27ae 9a0d cc2f 6ab0 17ce e552 0000130 af7b 6de9 a8f2 d5af 3317 df61 d2df a488 0000140 9917 0b61 8efa 13ca c1fe 2bec 1c35 608b 0000150 b516 2eef ef81 fa25 b4a8 242f 06e6 bb44 0000160 81ee 3bab 707e 2d3a b078 3981 0f05 3b5b 0000170 4ca9 6a9b 3370 5999 02d1 94a0 9cf4 cff2 0000180 f717 6a24 fe5b 4a34 3765 4a20 60c0 5238 0000190 4dc3 787b 7635 7f30 935b 5c22 8535 01ca 00001a0 1059 d5a9 af43 1792 666f 4bab 8d4b 3c2b 00001b0 0905 1a68 4d86 57b1 37e4 8d18 871b 820a 00001c0 0e62 c1af 1c52 9c49 c18d 48bc 45d6 6d5d 00001d0 bca2 dcd7 e22e 513d a2c2 3e8c de4a 7863 00001e0 9223 68dd c56d dc10 a1de a917 cc6e 60b9 00001f0 774d 343d b36b e922 32f1 7745 78dc 2072 0000200 The random bytes are still there, so this bug has been reproduced. Verified: Versions: Kernel:3.10.0-322.el7.x86_64 qemu-kvm-rhev:qemu-img-rhev-2.3.0-29.el7.x86_64 Steps: 1. create an empty qcow2 file # qemu-img create -f qcow2 /tmp/test.qcow2 64M 2. dd a file and association it with a loop device # dd if=/dev/urandom of=/tmp/test.raw bs=1M count=64 # losetup /dev/loop1 /tmp/test.raw # chmod 666 /dev/loop1 3. boot guest and do mirror job to the loop device # /usr/libexec/qemu-kvm \ -drive file=/tmp/test.qcow2,format=qcow2,if=none,id=drive-virtio-blk1,werror=stop,rerror=stop \ -device virtio-blk-pci,drive=drive-virtio-blk1,id=virtio-blk1 \ -monitor stdio (qemu) drive_mirror drive-virtio-blk1 /dev/loop1 raw (qemu) block_job_complete drive-virtio-blk1 (qemu) quit 4. check the loop device # sudo hexdump -n 512 /dev/loop1 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0000200 Only zero bytes are on the block device, so this bug has been fixed. 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://rhn.redhat.com/errata/RHBA-2015-2546.html |
Fixed upstream: commit 5279efebcf8f8fbf2ed2feed63cdb9d375c7cd07 Author: Jeff Cody <jcody> Date: Thu Oct 1 00:06:37 2015 -0400 block: mirror - fix full sync mode when target does not support zero init During mirror, if the target device does not support zero init, a mirror may result in a corrupted image for sync="full" mode. This is due to how the initial dirty bitmap is set up prior to copying data - we did not mark sectors as dirty that are unallocated. This means those unallocated sectors are skipped over on the target, and for a device without zero init, invalid data may reside in those holes. If both of the following conditions are true, then we will explicitly mark all sectors as dirty: 1.) sync = "full" 2.) bdrv_has_zero_init(target) == false If the target does support zero init, but a target image is passed in with data already present (i.e. an "existing" image), it is assumed