[Qemu-devel] [Bug 1422307] Re: qemu-nbd corrupts files

[Max Reitz]

First insight: Having the VDI image in tmpfs or using --cache=none for
qemu-nbd changes nothing, therefore the reason why dropping the caches
affects the result is probably Linux's cache for the NBD block device.

Second insight: Using blkverify makes it look very much like qemu's VDI
implementation is the culprit:

# for i in $(seq 0 9); do ./qemu-img create -f vdi /tmp/test.vdi 64M > 
/dev/null; ./qemu-img create -f raw /tmp/test.raw 64M > /dev/null; (./qemu-nbd 
-v -f raw -c /dev/nbd0 blkverify:/tmp/test.raw:/tmp/test.vdi &); sleep 1; 
./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 
/tmp/test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert 
/dev/nbd0 /tmp/test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img 
compare -q /tmp/test1.raw /tmp/test2.raw; then md5sum /tmp/test1.raw 
/tmp/test2.raw; echo "$i failed"; break; fi; done; echo 'done'
NBD device /dev/nbd0 is now connected to blkverify:/tmp/test.raw:/tmp/test.vdi
NBD device /dev/nbd0 is now connected to blkverify:/tmp/test.raw:/tmp/test.vdi
NBD device /dev/nbd0 is now connected to blkverify:/tmp/test.raw:/tmp/test.vdi
blkverify: read sector_num=27872 nb_sectors=256 contents mismatch in sector 
27904
blkverify: read sector_num=28128 nb_sectors=256 contents mismatch in sector 
28128
qemu-img: error while reading sector 24576: Input/output error
e5185b807948d65bb4e837d992cea429  /tmp/test1.raw
b8a195424a240ed77c849d89002fa23b  /tmp/test2.raw
2 failed
done

Max

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1422307

Title:
  qemu-nbd corrupts files

Status in QEMU:
  New

Bug description:
  Dear all,

  On Trusty, in certain situations, try to copy files over a qemu-nbd
  mounted file system leads to write errors (and thus, file corruption).

  Here is the last example I tried:
  -> virtual disk is a VDI disk
  -> It has only one partition, in FAT

  Here is my mount process:
  # modprobe nbd max_part=63
  # qemu-nbd -c /dev/nbd0 "virtual_disk.vdi"
  # partprobe /dev/nbd0
  # mount /dev/nbd0p1 /tmp/mnt/

  Partition is properly mounted at that point:
  /dev/nbd0p1 on /tmp/mnt type vfat (rw)

  Now, when I copy a file (rather big, ~28MB):
  # cp file_to_copy /tmp/mnt/ ; sync
  # md5sum /tmp/mnt/file_to_copy
  2efc9f32e4267782b11d63d2f128a363  /tmp/mnt/file_to_copy
  # umount /tmp/mnt 
  # mount /dev/nbd0p1 /tmp/mnt/
  # md5sum /tmp/mnt/file_to_copy
  42b0a3bf73f704d03ce301716d7654de  /tmp/mnt/file_to_copy

  The first hash was obviously the right one.

  On a previous attempt I did, I spotted thanks to vbindiff that parts of the 
file were just filed with 0s instead of actual data.
  It will randomly work after several attempts to write.

  Version information:
  # qemu-nbd --version
  qemu-nbd version 0.0.1
  Written by Anthony Liguori.

  Cheers,

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1422307/+subscriptions