On Wed, Jun 5, 2024 at 5:27 PM Justin <just...@safe-mbox.com> wrote:
> Hi. I'm using QEMU emulator version 5.2.0 on Linux. I am using > thick-provisioned RAW files as the VM backing store. I've found that > QEMU is punching holes in my RAW files (it's replacing some zero > blocks with holes), which means that the number of blocks allocated to > the VM volumes decreases. It keeps doing this; I've manually used > fallocate(1) to reallocate the full number of blocks to the VM backing > store files, and sometime later QEMU punches some more holes. > > How do I completely disable all hole punching? > > The problem with this behavious is that this confuses capacity > management software into thinking that there is enough free space to > create more VMs. The file-system for the VM backing stores becomes > over-committed. Later, when a VM starts writing non-zero data to the > holes, the VM hangs because QEMU cannot write to the backing store > because there are no free blocks available. There is no recovery other > than deleting files, so it basically means one or more VMs have to be > sacrificed for the greater good. > On the other hand, using a thin disk means that storage operations like copying a disk, backup or writing zeros are much more efficient. I would check if it is possible to fix the capacity management system to consider the disk virtual instead of available space. > I've run strace and I see calls to fallocate with these flags: > FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE > > I've tried passing these options: discard=off,detect-zeroes=off but > this does not help. This is the full set of relevant options I'm > using: > > -drive > file=/vms/vm0/drive,format=raw,if=virtio,discard=off,detect-zeroes=off > You don't need to disable detect-zeros - in my tests it makes dd if=/dev/zero 5 times faster (770 MiB/s -> 3 GiB/s) since zero writes are converted to fallocate(FALLOC_FL_KEEP_SIZE|FALLOC_FL_ZERO_RANGE). The issue seems to be ignoring the discard option when opening the image, and is fixed by this: https://lists.nongnu.org/archive/html/qemu-block/2024-06/msg00198.html I think the change needs more work to keep the default behavior since most users want sparse images, but it seems to do what you want - keeping images thick. Nir
