From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Warn if a qcow (not qcow2) file is opened Date: Tue, 30 Jun 2009 15:21:24 +0100 Message-ID: <200906301521.26152.paul@codesourcery.com> References: <1246284289-25394-1-git-send-email-avi@redhat.com> <4A4A13F7.8050904@codemonkey.ws> <4A4A19B7.3070600@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Anthony Liguori , Kevin Wolf , kvm@vger.kernel.org To: qemu-devel@nongnu.org Return-path: Received: from mail.codesourcery.com ([65.74.133.4]:38119 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbZF3OVY (ORCPT ); Tue, 30 Jun 2009 10:21:24 -0400 In-Reply-To: <4A4A19B7.3070600@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: > >>> 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. Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLeDH-0001zz-69 for qemu-devel@nongnu.org; Tue, 30 Jun 2009 10:21:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLeDC-0001yI-6K for qemu-devel@nongnu.org; Tue, 30 Jun 2009 10:21:34 -0400 Received: from [199.232.76.173] (port=59997 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLeDC-0001y3-0h for qemu-devel@nongnu.org; Tue, 30 Jun 2009 10:21:30 -0400 Received: from mx20.gnu.org ([199.232.41.8]:23004) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MLeDB-00082A-IM for qemu-devel@nongnu.org; Tue, 30 Jun 2009 10:21:29 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLeDA-0003dp-Jf for qemu-devel@nongnu.org; Tue, 30 Jun 2009 10:21:28 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Warn if a qcow (not qcow2) file is opened Date: Tue, 30 Jun 2009 15:21:24 +0100 References: <1246284289-25394-1-git-send-email-avi@redhat.com> <4A4A13F7.8050904@codemonkey.ws> <4A4A19B7.3070600@redhat.com> In-Reply-To: <4A4A19B7.3070600@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906301521.26152.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , Avi Kivity , kvm@vger.kernel.org > >>> 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. Paul