1 files changed, 38 insertions, 0 deletions
diff --git a/results/classifier/105/graphic/1376938 b/results/classifier/105/graphic/1376938
new file mode 100644
index 00000000..c63f72a6
--- /dev/null
+++ b/results/classifier/105/graphic/1376938
@@ -0,0 +1,38 @@
+graphic: 0.496
+device: 0.409
+instruction: 0.314
+KVM: 0.202
+semantic: 0.165
+boot: 0.147
+other: 0.124
+mistranslation: 0.120
+network: 0.100
+socket: 0.080
+vnc: 0.073
+assembly: 0.037
+
+detect-zeroes=unmap fails to discard in some cases
+
+Under certain circumstances, QEMU 2.1.2 fails to discard the underlaying block. The command to start QEMU is:
+
+qemu-system-x86_64 -machine pc,accel=kvm -m 2G -smp 2 -vga std -usb -usbdevice tablet -drive if=none,id=ff,aio=native,discard=unmap,detect-zeroes=unmap,file=/tmp/test.qcow2 -device virtio-scsi-pci -device scsi-disk,drive=ff -cdrom /media/iso/archlinux-2014.06.01-dual.iso -vnc :1
+
+Steps to reproduce:
+
+ 0. qemu-img create -f qcow2 /tmp/test.qcow2 4G
+ 1. Boot in the guest (Arch Linux x86_64 with Linux 3.14.4)
+ 2. cat /dev/zero > /dev/sda. Observe a file of 4109M (size measured with `du -m`
+ 3. cat /dev/zero > /dev/sda
+ 4. blkdiscard /dev/sda
+ 5. Observe that test.qcow2 grows larger than 1M (13M in my testing).
+
+The results are more severe when you write other kind of data in step 2, for instance `base64 /dev/zero > /dev/sda` and then continuing with step 3 and 4 will result in a file of 3642M, after blkdiscard.
+
+It makes not much of a difference if I create an ext4 filesystem on top of it and use fstrim (or rm).
+
+Note that `cat /dev/zero` followed by `blkdiscard` has no issues.
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+