detect-zeroes=unmap fails to discard in some cases

Bug #1376938 reported by Peter Wu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Expired
Undecided
Unassigned

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).

Revision history for this message
Peter Wu (lekensteyn) wrote :

Note that `cat /dev/zero` followed by `blkdiscard` has no issues.

Revision history for this message
Thomas Huth (th-huth) wrote :

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
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.