From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqKnb-0004K9-AR for qemu-devel@nongnu.org; Thu, 07 May 2015 08:21:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqKnU-0001O6-BJ for qemu-devel@nongnu.org; Thu, 07 May 2015 08:21:07 -0400 Sender: Paolo Bonzini Message-ID: <554B58A8.6000203@redhat.com> Date: Thu, 07 May 2015 14:20:56 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1426791801-9042-1-git-send-email-mreitz@redhat.com> <20150505094606.GB29818@stefanha-thinkpad.redhat.com> <554A1160.7020200@redhat.com> <554A3395.7050509@redhat.com> <554A3D7B.3040603@redhat.com> <554A3F37.9080704@redhat.com> <554A4349.10301@redhat.com> <554A459B.1060505@redhat.com> <554A4E2D.4050300@redhat.com> In-Reply-To: <554A4E2D.4050300@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: Max Reitz , Stefan Hajnoczi Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org On 06/05/2015 19:23, Max Reitz wrote: > The guest sees whatever has been written into reply->error, and that > field hasn't been written by this function in that case. It has been > written by nbd_receive_reply() in nbd.c, and that value comes directly > from the server. In case of qemu-nbd being the server, a write beyond > the EOF should be caught by blk_check_byte_request() in > block/block-backend.c, which returns -EIO. So that's where the EIO comes > from. Fair enough. This makes sense, but then we have to create ENOSPC elsewhere. > I don't know whether this EIO is subsequently converted to ENOSPC > because of werror=enospc, but considering that > https://bugzilla.redhat.com/show_bug.cgi?id=1090713 did not override > werror, it doesn't look like it. No, it shouldn't indeed. Could alloc_clusters_noref do bdrv_truncate and return ENOSPC if it fails? That's how for example qcow and vhdx work. vdi has the same problem. Paolo