From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypz0F-00082J-EV for qemu-devel@nongnu.org; Wed, 06 May 2015 09:04:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypz0E-0004XW-BU for qemu-devel@nongnu.org; Wed, 06 May 2015 09:04:43 -0400 Message-ID: <554A1160.7020200@redhat.com> Date: Wed, 06 May 2015 15:04:32 +0200 From: Max Reitz MIME-Version: 1.0 References: <1426791801-9042-1-git-send-email-mreitz@redhat.com> <20150505094606.GB29818@stefanha-thinkpad.redhat.com> In-Reply-To: <20150505094606.GB29818@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/3] block: Warn about usage of growing formats over non-growable protocols List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org On 05.05.2015 11:46, Stefan Hajnoczi wrote: > On Thu, Mar 19, 2015 at 03:03:18PM -0400, Max Reitz wrote: >> Some image formats (e.g. qcow2) require the underlying file to grow on >> write accesses, but this is in fact not supported by all protocols (e.g. >> nbd does not). If such a format requiring file growth is used >> non-read-only over a protocol which does not support this, a warning >> should be issued. >> >> This warning is issued for example whenever one tries to export a qcow2 >> image over nbd-server and use the export from qemu. > The warning implies that the user should switch to read-only or a > different protocol, but this configuration is perfectly normal. For > example, oVirt uses qcow2 on LVM volumes. > > Introducing a warning for a normal QEMU invocation is a bit weird. > > What is the point of this series? Were users confused that they hit > ENOSPC? Users were confused when exporting a qcow2 image using nbd-server instead of qemu-img, and then accessing that NBD export with qemu (subsequently getting I/O errors on guest writes, if the image is not yet fully allocated): http://bugzilla.redhat.com/show_bug.cgi?id=1090713 Max