From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33343)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1YqMGl-0002es-DP
	for qemu-devel@nongnu.org; Thu, 07 May 2015 09:55:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1YqMGk-0002jt-MG
	for qemu-devel@nongnu.org; Thu, 07 May 2015 09:55:19 -0400
Message-ID: <554B6EBB.1010001@redhat.com>
Date: Thu, 07 May 2015 15:55:07 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <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> <554B58A8.6000203@redhat.com>
	<20150507122911.GB4571@noname.redhat.com>
	<554B5ED3.4030405@redhat.com>
	<20150507132056.GC4571@noname.redhat.com>
In-Reply-To: <20150507132056.GC4571@noname.redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about
 usage of growing formats over non-growable protocols
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, Max Reitz <mreitz@redhat.com>



On 07/05/2015 15:20, Kevin Wolf wrote:
> > Does ENOSPC over LVM (dm-linear) work at all, and who generates the
> > ENOSPC there?
>
> The LVM use case is what oVirt uses, so I'm pretty sure that it works.
> I'm now sure who generates the ENOSPC, but it's not qemu anyway. If I
> had to guess, I'd say that the kernel block layer might just forbid
> writing after EOF for any block device.

Indeed, though it's VFS (blkdev_write_iter in fs/block_dev.c) and not
the block layer.  It looks like we need this:

diff --git a/block/block-backend.c b/block/block-backend.c
index 93e46f3..e54c433 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -461,7 +461,7 @@ static int blk_check_byte_request(BlockBackend *blk, =
int64_t offset,
     }
=20
     if (offset > len || len - offset < size) {
-        return -EIO;
+        return -ENOSPC;
     }
=20
     return 0;

Paolo