Until now I've enabled discard on my QEMU guests using the libvirt XML command

<driver name='qemu' type='qcow2' discard='unmap' />

And it seems to work fine.

Now that I'm about to convert my storage from virtio-scsi to virtio-blk because it now support discard, I ran into the option detect_zeroes=off|on|unmap (or QEMUs equivalent detect-zeroes)

Should I also use this option and why? I assume beside the areas will be marked "available" by discard they are also written by zeroes, but what values does it have, especially on SSD backed storage?

Using qcow2 images I see the point of writing zeros to mark the empty space sparsed, but it seems the qcow2 image files are actually getting smaller (sparsed) without this option and just using discard='unmap'.

The libvirt documentation says:

The optional detect_zeroes attribute controls whether to detect zero write requests. The value can be "off", "on" or "unmap". First two values turn the detection off and on, respectively. The third value ("unmap") turns the detection on and additionally tries to discard such areas from the image based on the value of discard above (it will act as "on" if discard is set to "ignore"). NB enabling the detection is a compute intensive operation, but can save file space and/or time on slow media. Since 2.0.0

Which unfortunately didn't got me closer to a decision of using detect_zeroes or not :-/

Backing storage for my QEMU guests are both qcow2 images on HDD and SSD and LVM block devices located on SSD.


Modern operating systems are capable of sending TRIM/UNMAP commands to the virtual storage to free up the space, so detect_zeroes is not necessary for such OSes.

The only reason I can think of to use detect_zeroes is to gain discard support for an ancient operating system that doesn't support TRIM/UNMAP. In this case blocks of zeroes will be unmapped when you set detect_zeroes='unmap' instead of blocks of zeroes being written to disk. In the virtual guest OS you would run some utility that writes zeroes to all the free space on the disk, and KVM will convert these to TRIM/UNMAP. This can be CPU intensive though. Also, I can't figure any good reason to have it on without unmap.

P.S. You said: "Now that I'm about to convert my storage from virtio-scsi to virtio-blk" ... Did you get these backward? Normally you convert from virtio-blk to virtio-scsi.

  • Thanks! Yes, I sure is moving from virtio-scsi to virtio-blk, as according to RHEL the later is more performant. See this PDF Storage-Performance-Tuning-for-FAST-Virtual-Machines. And lately got support for discard. Haven't done any benchmark though. – MrCalvin Jun 24 '20 at 5:31
  • That's pretty out of date, and the performance difference was minimal even then. Today virtio-scsi is multithreaded and significantly outperforms virtio-blk on most realistic workloads. It was specifically designed to replace virtio-blk, which is now on its way out and will eventually be dropped. – Michael Hampton Jun 24 '20 at 11:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.