On Thu, Jun 28, 2018 at 12:35:56PM +0200, Gionatan Danti wrote: > Il 26-06-2018 23:49 Cole Robinson ha scritto: > > I see it as another test case and larger UI surface in the common path > > for something that will save clicks for a corner case. I still don't see > > it asworth exposing in the UI. > > > > - Cole > > I can not force this decision, obviously. However, let me recap why I found > it important to have the "allocate disk now" checkbox: > > - RAW files, even sparse one, are faster than Qcow2 files in the long run > (ie: when block allocation is >8 GB); There is always a performance distinction between raw and qcow2, but it is much less these days with qcow2v3 than it was with the original qcow2 design. > - Qcow2 snapshots have significant gotchas (ie: the guest is suspended > during the snapshot), while using RAW files will at least prevent using > virt-manager snapshot feature without thinking; This is really tangential. virt-manager chose to use internal snapshots because they were easy to support, but it could equally use external snapshots. This shouldn't have a bearing on other choices - if the internal snapshotting is unacceptable due to the guest pause, this needs addressing regardless of allocation. > - on CoW filesystems, using Qcow2 files will means *double* CoW with a) > reduced performance and b) more wear on SSDs; Using qcow2 doesn't require you to use cow at the disk image layer - it simply gives you the ability, should you want to. So you don't get double cow by default > - on filesystems not supporting fallocate, libvirtd reverts to "write zeroes > to the entire file) which is both a) very slow and b) detrimental to SSDs > life; Which widely used modern filesystems still don't support fallocate. It is essentially a standard feature on any modern production quality filesystem these days. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
