Re: [libvirt] Semantic change in v4.3 slows down image creation and snapshots (on ZFS)
On Wed, Oct 09, 2019 at 13:39:54 +0200, Christian Ehrhardt wrote:
Hi,
when discussing bug [1] triggered by [2] Daniel and I have found that
the change [3] which is in since v4.3 was a semantic change to the
behavior of libvirt.
virt-manager used and still does issue a volume XML like:
<volume>
<name>disk.qcow2</name>
<capacity>16106127360</capacity>
<allocation>16106127360</allocation>
<target>
<format type="qcow2"/>
<features>
<lazy_refcounts/>
</features>
</target>
</volume>
Up until the commit above that was using preallocation=metadata, but
now uses preallocation=falloc. In many cases (read: Fileystems) that
won't be very user-visible, but if you are running on ZFS (or anything
else that can't fallocate well) this is made worse by [4] slowing down
these operations a lot.
Note that for raw files we would do preallocation for the full image but
only when fast allocation is supported. See 'createRawFile'.
After the POV for virt-manager seems to have settled on the bug [1]
referenced the remaining question is if libvirt should revert/modify
the change [3] - and that we agreed required a wider discussion to be
had here, hence this mail.
Semantically the change above would make sense if it weren't coupled to
the presence of VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA.
The flags semantics imply that metadata allocation is requested and thus
metadata should be allocated.
On the other hand doing full allocation if the flag is not present but
the XML calls for it would semantically be okay IMO.
I'm not sure if that is what you expect though.