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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
