Bug 1136382 - block: Mirroring to raw block device doesn't zero out unused blocks
Summary: block: Mirroring to raw block device doesn't zero out unused blocks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jeff Cody
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 971297
Blocks: 971312
TreeView+ depends on / blocked
 
Reported: 2014-09-02 13:11 UTC by Jeff Cody
Modified: 2015-12-04 16:18 UTC (History)
13 users (show)

Fixed In Version: qemu-kvm-rhev-2.3.0-28.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 971297
Environment:
Last Closed: 2015-12-04 16:18:30 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2546 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2015-12-04 21:11:56 UTC

Comment 5 Jeff Cody 2015-10-02 14:05:06 UTC
Fixed upstream:

commit 5279efebcf8f8fbf2ed2feed63cdb9d375c7cd07
Author: Jeff Cody <jcody@redhat.com>
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

Comment 6 Miroslav Rezanina 2015-10-05 05:22:59 UTC
Fix included in qemu-kvm-rhev-2.3.0-28.el7

Comment 7 Pei Zhang 2015-10-09 00:52:12 UTC
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.

Comment 8 juzhang 2015-10-09 01:40:09 UTC
According to comment7, set this issue as verified.

Comment 10 errata-xmlrpc 2015-12-04 16:18:30 UTC
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


Note You need to log in before you can comment on or make changes to this bug.