On 06/06/2018 09:57 AM, Eric Blake wrote:
On 06/06/2018 09:43 AM, Michael S. Tsirkin wrote:
On Wed, Jun 06, 2018 at 01:02:53PM +0200, Max Reitz wrote:
Yeah, but why make qcow2 that format? That's what I completely fail to
understand.
Because why not? It's cheap to add it there and is much easier
than teaching people about a new container format.
tar is not a new container format, but it is a new format to various
toolchains - that said, if we popularize tar as the format for including
a config file alongside a qcow2 image, it's not that hard to fix the
stack to start passing that file around as the new preferred file type.
On a completely different front, 'qcow2' as a file format comes with
some psychological baggage. If someone was using it 8 years ago, before
we did coroutine optimizations, it was noticeably slower than raw, and
relatively easier to get into a corrupted image condition that resulted
in data loss. Just one VM lost, and it leaves a sour taste in your
mouth, where you are unwilling to trust that file format (even though
the file format was not necessarily the cause of the corruption).
Marketing-wise, we failed with our improvements ('qcow2v3' is so much
more of a mouthful than 'qcow3'), and it took years to flip the defaults
from v2 as the default to v3 as the default (moreso in downstream
distros than upstream), in part because we couldn't convince people of
the improvements they would be gaining by moving to v3. Historically,
there's also 'qed' which was promised as a way to fix some of the poor
performance of qcow2, but which ended up not being any better than our
actual qcow2v3 improvements, so no one ended up switching to that. So,
to some extent, various high-level consumers still have the notion that
'raw' files are better/safer/faster than 'qcow2' files because of an
anecdote from years ago, even if we have since fixed the speed parity
and added locking to eliminate careless data loss.
If we DO add a new tar-file block driver to qemu, that could serve as a
marketing opportunity to convince people that the new format has all of
the features that you can't get from just a raw file, and does not
suffer from the slowness or data corruption they were worried about in
qcow2. Thus, even if our new format is just a thin wrapper around a
config file plus the existing qcow2v3 we already know and love, the mere
fact that it is a new format may get people to move away from raw images
in situations where just the name 'qcow2' is unable to do so, at which
point we can help them take advantage of the features made possible by
qcow2.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
