[Bug 1422307] [NEW] qemu-nbd corrupts files
Launchpad Bug Tracker
1422307 at bugs.launchpad.net
Wed Aug 19 07:36:38 UTC 2015
You have been subscribed to a public bug by Robie Basak (racb):
[Impact]
A race condition in the VDI block driver of Qemu leads to image (and thus file system) corruption under certain circumstances.
This makes Qemu tools usage for VDI formatted images particularly dangerous (qemu-img, qemu-nbd).
The bug fix introduces locks to prevent such race condition.
[Test Case]
A simple test case was provided in comment #5 (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1422307/comments/5):
$ ./qemu-img create -f vdi test.vdi 2G
Formatting 'test.vdi', fmt=vdi size=2147483648 static=off
$ ./qemu-img create -f raw test.raw 2G
Formatting 'test.raw', fmt=raw size=2147483648
$ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=blkverify:test.raw:test.vdi,format=raw -drive if=virtio,file=data.img,format=raw,format=raw -cdrom ~/tmp/arch.iso -m 512 -boot d
blkverify: read sector_num=810976 nb_sectors=256 contents mismatch in sector 811008
Operations in the guest:
$ dd if=/dev/vdb of=/dev/vda
$ dd if=/dev/vda of=/dev/null
[Regression Potential]
In case of bugs affecting the way locks are used, deadlocks could be a regression, but they would only affect VDI images.
Original bug report:
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,
** Affects: qemu
Importance: Undecided
Status: Fix Released
** Affects: qemu (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: qemu (Ubuntu Trusty)
Importance: Medium
Status: Triaged
--
qemu-nbd corrupts files
https://bugs.launchpad.net/bugs/1422307
You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to the bug report.
More information about the Ubuntu-server-bugs
mailing list