Virtual Machines - add detect-zeroes to QEMU startup command

Feature Requests
1

Problem/Justification

add detect-zeroes to the startup command

  • and maybe use the option unmap rather than on so it matches with the discard command
  • here is an example partial startup command showing the current discard setting passed
-blockdev {"driver":"host_device","filename":"/dev/zvol/tank/vms/ubuntu-rlsb54","aio":"threads","node-name":"libvirt-1-storage","read-only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false}}
-device {"driver":"virtio-blk-pci","bus":"pci.0","addr":"0x7","drive":"libvirt-1-storage","id":"virtio-disk0","bootindex":2,"logical_block_size":4096,"physical_block_size":4096,"write-cache":"on","serial":"1qiLfsam"}

Impact
This will allow better handling of zeros which can be passed upstream to the ZFS system allowing for better space management

I am not sure if this make the system perform better or worse but shuld be good for space usage.

this is an a old article I found, but with modern hardware might not be relevant.

Should I use “detect-zeroes” for TRIM/discard support on QEMU guests? | Server Vault

User Story
n/a

2

This isn’t strictly required on ZFS in modern times for a few reasons:

  • A guest OS has very little reason to write significant amounts of contiguous zeros that could be detected in the first place. TRIM is supported by everything not EOL, sparse files, delayed allocation and smart falloc/truncate are also common.
  • ZFS with either compression or deduplication enabled already does this: zero filled records/blocks are allocated as sparse “holes”
  • ZFS compression is actually superior, because it also reduces space usage when just some of a block, not the entire thing is zero.

So for this to make sense the system would have to run:

  • An EOL guest (or one very fond of dding /dev/zero into files)
  • With compression completely disabled (which often performs worse than LZ4)

AND you’d have to show that this “detection” and the trim/unmap requests generated by it, as well as the unmap request processing in ZFS are faster than the zero detection natively build into ZFS. Especially for edge cases like smaller unmap requests generated against partial zvol blocks (512/4096 Byte vs the 16 KB zVOL block size) and potential fragmentation.

3

I hear what you are saying and would just like to point out that people run old OSes in virtual machines.

Maybe it should be optional?

4

Again, even with an old guest OS it’d first have to be shown that this feature is first of all safe to use (in this particular constellation of VM config, backing storage and software versions) and secondly actually an improvement in performance compared to the mechanisms already built into ZFS.

Zero detection is already transparently happening on the ZFS side, so doing it twice, once in a userspace block dev emulation driver, only to potentially be ignored by ZFS based on a variety of internal criteria and then again during the txg sync phase seems dubious.

Especially because the QEMU zero detection feature is not widely used. Libvirt, Proxmox and other projects alike either don’t set it as default or don’t even expose it at all. And there have been documented cases of (at least) instability, potentially even data loss related to it.