到目前为止，我已经使用 libvirt XML 命令在 QEMU 客户机上启用了丢弃
..
<driver name='qemu' type='qcow2' discard='unmap' />
..
而且它似乎运行良好。
现在我即将转换我的存储，virtio-scsi因为virtio-blk它现在支持丢弃，我遇到了选项detect_zeroes=off|on|unmap（或 QEMU 等效detect-zeroes）
我也应该使用此选项吗？为什么？我假设除了将被丢弃标记为“可用”的区域之外，它们也由零写入，但它具有什么值，特别是在 SSD 支持的存储上？
使用 qcow2 图像时，我明白写入零来标记空白空间稀疏的意义，但似乎没有这个选项而只是使用 ，qcow2 图像文件实际上变得更小（稀疏）discard='unmap'。
libvirt 文档说：
可选的detect_zeroes属性控制是否检测零写入请求。该值可以是“off”、“on”或“unmap”。前两个值分别关闭和打开检测。第三个值（“unmap”）打开检测，并根据上面的discard值尝试从图像中丢弃这些区域（如果discard设置为“ignore”，它将作为“on”）。NB启用检测是一项计算密集型操作，但可以节省文件空间和/或慢速媒体的时间。自2.0.0起
不幸的是，这并没有让我做出detect_zeroes是否使用的决定:-/
我的 QEMU 客户的后备存储是 HDD 和 SSD 上的 qcow2 映像以及位于 SSD 上的 LVM 块设备。
答案1
现代操作系统能够向虚拟存储发送 TRIM/UNMAP 命令来释放空间，因此detect_zeroes对于此类操作系统来说这不是必需的。
我能想到使用的唯一原因detect_zeroes是获得对不支持 TRIM/UNMAP 的古老操作系统的丢弃支持。在这种情况下，当您设置detect_zeroes='unmap'而不是将零块写入磁盘时，零块将被取消映射。在虚拟客户操作系统中，您将运行一些实用程序，将零写入磁盘上的所有可用空间，KVM 会将这些转换为 TRIM/UNMAP。不过，这可能会占用大量 CPU。另外，我想不出有什么好的理由不使用on它unmap。
PS 您说：“现在我要将我的存储从 转换virtio-scsi为virtio-blk”... 您是不是搞反了？通常您会将 转换virtio-blk为virtio-scsi。