From: "Daniel P. Berrange" <berrange@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Kevin Wolf <kwolf@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] Warn if a qcow (not qcow2) file is opened
Date: Tue, 30 Jun 2009 15:40:58 +0100 [thread overview]
Message-ID: <20090630144058.GD5056@redhat.com> (raw)
In-Reply-To: <200906301521.26152.paul@codesourcery.com>
On Tue, Jun 30, 2009 at 03:21:24PM +0100, Paul Brook wrote:
> > >>> The qcow block driver format is no longer maintained and likely
> > >>> contains
> > >>> serious data corruptors. Urge users to stay away for it, and advertise
> > >>> the new and improved replacement.
> > >
> > > I'm not sure how I feel about this. Can we prove qcow is broken? Is
> > > it only broken for writes and not reads?
> >
> > Well, Kevin posted a patch, so it is. It's definitely unmaintained.
> > Given it's a qemu native format, there is no interoperability value
> > except with old qemu versions.
> >
> > > If we're printing a warning, does that mean we want to deprecate qcow
> > > and eventually remove it (or remove write support, at least)?
> >
> > Yes.
>
> IMHO there's little value in just printing a warning. Until it actually goes
> away, people are liable to assume we're just being paranoid/awkward and keep
> using it anyway.
>
> I suggest crippling it now and, assuming noone steps up to fix+maintain it,
> ripping out the write support altogether at next release.
> I'm assuming the readonly code is in better shape, and can be supported with
> relatively little effort.
I agree, if we want to phase it out we should be more discouraging than
just an ignoreable warning
- Disable it in qemu, and have code which looks for qcow1 magic
bytes, prints an error message telling them to use qemu-img
to convert to qcow2 and exits
- Keep qcow1 in qemu-img as a source format only, to allow conversions
to qcow2
Possibly have a 'configure' arg to let people re-enable full read-write
it if they badly need it, but tell them it'll be gone permanently in
release qemu-0.12.0
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org,
Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Warn if a qcow (not qcow2) file is opened
Date: Tue, 30 Jun 2009 15:40:58 +0100 [thread overview]
Message-ID: <20090630144058.GD5056@redhat.com> (raw)
In-Reply-To: <200906301521.26152.paul@codesourcery.com>
On Tue, Jun 30, 2009 at 03:21:24PM +0100, Paul Brook wrote:
> > >>> The qcow block driver format is no longer maintained and likely
> > >>> contains
> > >>> serious data corruptors. Urge users to stay away for it, and advertise
> > >>> the new and improved replacement.
> > >
> > > I'm not sure how I feel about this. Can we prove qcow is broken? Is
> > > it only broken for writes and not reads?
> >
> > Well, Kevin posted a patch, so it is. It's definitely unmaintained.
> > Given it's a qemu native format, there is no interoperability value
> > except with old qemu versions.
> >
> > > If we're printing a warning, does that mean we want to deprecate qcow
> > > and eventually remove it (or remove write support, at least)?
> >
> > Yes.
>
> IMHO there's little value in just printing a warning. Until it actually goes
> away, people are liable to assume we're just being paranoid/awkward and keep
> using it anyway.
>
> I suggest crippling it now and, assuming noone steps up to fix+maintain it,
> ripping out the write support altogether at next release.
> I'm assuming the readonly code is in better shape, and can be supported with
> relatively little effort.
I agree, if we want to phase it out we should be more discouraging than
just an ignoreable warning
- Disable it in qemu, and have code which looks for qcow1 magic
bytes, prints an error message telling them to use qemu-img
to convert to qcow2 and exits
- Keep qcow1 in qemu-img as a source format only, to allow conversions
to qcow2
Possibly have a 'configure' arg to let people re-enable full read-write
it if they badly need it, but tell them it'll be gone permanently in
release qemu-0.12.0
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2009-06-30 14:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 14:04 [PATCH] Warn if a qcow (not qcow2) file is opened Avi Kivity
2009-06-29 14:04 ` [Qemu-devel] " Avi Kivity
2009-06-30 8:34 ` Kevin Wolf
2009-06-30 13:32 ` Anthony Liguori
2009-06-30 13:32 ` Anthony Liguori
2009-06-30 13:53 ` Kevin Wolf
2009-06-30 13:57 ` Avi Kivity
2009-06-30 13:57 ` [Qemu-devel] " Avi Kivity
2009-06-30 14:21 ` Paul Brook
2009-06-30 14:21 ` Paul Brook
2009-06-30 14:40 ` Daniel P. Berrange [this message]
2009-06-30 14:40 ` Daniel P. Berrange
2009-06-30 16:42 ` Anthony Liguori
2009-06-30 16:42 ` [Qemu-devel] " Anthony Liguori
2009-07-01 17:14 ` Andreas Färber
2009-07-02 7:22 ` Kevin Wolf
2009-07-02 7:22 ` Kevin Wolf
2009-06-30 12:05 ` Amit Shah
2009-06-30 12:05 ` [Qemu-devel] " Amit Shah
2009-06-30 12:53 ` Kevin Wolf
2009-06-30 12:53 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090630144058.GD5056@redhat.com \
--to=berrange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.