Hide Forgot
Description of problem: Boot a RHEL5.10 guest attched a libiscsi data disk, dd a file in this libiscsi data disk, check the MD value of this file, run "sync" and then cut off the host power immediately after fsync command return. Boot host and guest, found the MD value is changed. Version-Release number of selected component (if applicable): qemu-kvm-rhev-1.5.3-20.el7.x86_64 kernel-3.10.0-57.el7.x86_64 RHEL5.10 guest: kernel-2.6.18-371.el5 How reproducible: 100% Steps to Reproduce: 1. Boot a RHEL5.10 guest, attached a libiscsi data disk # /usr/libexec/qemu-kvm -M q35 -cpu SandyBridge -enable-kvm -m 2048 -smp 2,sockets=1,cores=2,threads=1 -name rhel7 -uuid 6afa5f93-2d4f-420f-81c6-e5fdddbd1c83 -drive file=iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/1,if=none,id=drive-virtio-disk0,format=qcow2,serial=40c061dd-5d60-4fc5-865f-55db700407f0,werror=stop,rerror=stop,aio=threads,cache=none -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0a:00 -vnc :1 -monitor stdio -spice port=5900,disable-ticketing -qmp tcp:0:4445,server,nowait -drive file=iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/4,if=none,id=drive-virtio-disk1,format=qcow2,serial=40c061dd-5d60-4fc5-865f-55db700407f0,werror=stop,rerror=stop,aio=threads,cache=none -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk1,id=virtio-disk1 2. In guest, create a primary partition and make ext3 filesystem # fdisk /dev/vdb # mkfs.ext3 /dev/vdb1 3. In guest, dd a file, check MD value and run "sync" # dd if=/dev/urandom of=file1 bs=1M count=512 ; md5sum file1 ; sync 4. cut off the host power immediately after sync command return 5. Boot host and guest, check the MD5 value in guest Actual results: The MD5 value of step3 is: 01b1dd504106f9cd6fa0536fc4a67252 The MD5 value of step5 is: 8565f264753d432025ab0b96d8f1267a Expected results: The MD5 value of step3 and step5 should be same. Additional info:
sync may not be enough. Try using virtio-scsi and "sync; sg_sync /dev/sdX".
(In reply to Paolo Bonzini from comment #2) > sync may not be enough. Try using virtio-scsi and "sync; sg_sync /dev/sdX". Hi Huiding, Could you please have a try and update the testing result in the bz? Best Regards, Junyi
(In reply to Paolo Bonzini from comment #2) > sync may not be enough. Try using virtio-scsi and "sync; sg_sync /dev/sdX". Hello, Paolo I test RHEL7.0 guest using virtio-blk and virtio-scsi. Not hit this bug. Since the kernel of RHEL5.10 has not the driver of virtio-scsi, I cannot test this bug using virtio-scsi.
On virtio-blk you can replace sg_sync /dev/sdX with this C program: #include <fcntl.h> #include <unistd.h> int main(int argc, char **argv) { if (argc == 1) return 1; int fd = open(argv[1], O_RDWR); fsync(fd); }
(In reply to Paolo Bonzini from comment #5) > On virtio-blk you can replace sg_sync /dev/sdX with this C program: > > #include <fcntl.h> > #include <unistd.h> > > int main(int argc, char **argv) > { > if (argc == 1) return 1; > int fd = open(argv[1], O_RDWR); > fsync(fd); > } Hello, Paolo I use the above C program to sync my virtio-blk device. But the MD5 values are also different.
I think this is a rhel5 kernel bug.