Re: Semantic change in v4.3 slows down image creation and snapshots (on ZFS)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 9, 2019 at 8:33 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
> On Wed, Oct 09, 2019 at 02:25:09PM +0200, Peter Krempa wrote:
> > On Wed, Oct 09, 2019 at 13:39:54 +0200, Christian Ehrhardt wrote:
> > > Up until the commit above that was using preallocation=metadata, but
> > > now uses preallocation=falloc.
>
> > 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.
>
> Yeah, I agree with this.
>
> > I'm not sure if that is what you expect though.
>
> virt-manager passes VOL_CREATE_PREALLOC_METADATA, so honouring that flag
> correctly would fix the problem reported with ZFS.

I know that this is an old message, but I'm just getting around to updating
some of my libvirt-python scripts and I'm encountering a similar problem to
virt-manager when using libvirt >=4.3, without the ZFS part.

Prior to libvirt v4.3, my script created qcow2-format StorageVolumes with a
<capacity/> element, and no <allocation/> element. It used the flag
VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA to request metadata-only
prealloc, which the documentation of virStorageVolCreateXml describes
as creating
a sparse file:

> Since 1.0.1 VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA in flags
> can be used to get higher performance with qcow2 image files which don't support
> full preallocation, by creating a sparse image file with metadata.

The patch identified in this thread does not create a sparse file even in the
presence of this flag when the requested capacity is equal to the requested
allocation.

You could just update the documentation to match current behavior, but I
think that this is a bug and that qemu-img's prealloc=metadata option should
always be used when VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA
is specified.

It also seems that the documentation is out-of-date in regards to qcow2 not
supporting full preallocation.

As mentioned previously, using the StorageVolume's <allocation /> element as
an input does not work for qcow2. The requested allocation size is never
honored by qemu-img. There is no concept of partial preallocation. There is only
full prealloc and sparse metadata prealloc.

Thanks,
Mike





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux