Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1376938 Title: detect-zeroes=unmap fails to discard in some cases Status in QEMU: Incomplete Bug description: 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). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1376938/+subscriptions