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 :|