[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1422307] Re: qemu-nbd corrupts files
From: |
Max Reitz |
Subject: |
[Qemu-devel] [Bug 1422307] Re: qemu-nbd corrupts files |
Date: |
Tue, 17 Feb 2015 18:22:38 -0000 |
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