From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqMbi-0005tT-Jh for qemu-devel@nongnu.org; Thu, 07 May 2015 10:17:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqMbe-0002XP-95 for qemu-devel@nongnu.org; Thu, 07 May 2015 10:16:58 -0400 Message-ID: <554B73C2.4030908@redhat.com> Date: Thu, 07 May 2015 16:16:34 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <554A3D7B.3040603@redhat.com> <554A3F37.9080704@redhat.com> <554A4349.10301@redhat.com> <554A459B.1060505@redhat.com> <554A4E2D.4050300@redhat.com> <554B58A8.6000203@redhat.com> <20150507122911.GB4571@noname.redhat.com> <554B5ED3.4030405@redhat.com> <20150507132056.GC4571@noname.redhat.com> <554B6EBB.1010001@redhat.com> <20150507140716.GE4571@noname.redhat.com> In-Reply-To: <20150507140716.GE4571@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [Qemu-block] [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: Kevin Wolf Cc: Stefan Hajnoczi , qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz On 07/05/2015 16:07, Kevin Wolf wrote: > This is not right for two reasons: The first is that this is > BlockBackend code I think it would take effect for the qemu-nbd case though. > and it wouldn't even take effect for the qcow2 case > where we're writing past EOF only on the protocol layer. The second is > that -ENOSPC is only for writes and not for reads. This is right. Reads in the kernel return 0, but in QEMU we do not want that. The code currently returns -EIO, but perhaps -EINVAL is a better match. It also happens to be what Linux returns for discards. Paolo > For the protocol level, bdrv_aligned_preadv() has code to handle reads > past EOF if bs->zero_beyond_eof is set. This is always the case, except > for qcow2, which has the snapshot VM state after EOF, so the driver is > called for that. > > For writes, the driver is always called. The expectiation is that beyond > EOF it resizes the image file if it can, and returns -ENOSPC if it can't. > We could change this to have a check directly in bdrv_aligned_pwrite() > and then drivers would have to advertise whether they can extend a file > beyond EOF or not so we know whether to apply the check or not > (essentially the growable flag that Max wants to add), but I'm not sure > what we would win with that.