From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqfLD-0006aS-0X for qemu-devel@nongnu.org; Fri, 08 May 2015 06:17:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqfLB-0007qd-VT for qemu-devel@nongnu.org; Fri, 08 May 2015 06:17:10 -0400 Message-ID: <554C8D1B.8030307@redhat.com> Date: Fri, 08 May 2015 12:16:59 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <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> <554B73C2.4030908@redhat.com> <20150507143418.GF4571@noname.redhat.com> <554B7BBC.2040508@redhat.com> <20150508100832.GC4318@noname.redhat.com> In-Reply-To: <20150508100832.GC4318@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 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: 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 08/05/2015 12:08, Kevin Wolf wrote: > Actually, considering all the information in this thread, I'm inclined > that we should change both sides. qemu-nbd because ENOSPC might be what > clients expect by analogy with Linux block devices, even if the > behaviour for accesses beyond the device size isn't specified in the NB= D > protocol and the server might just do anything. As long as the behaviou= r > is undefined, it's nice to do what most people may expect. >=20 > And as the real fix change the nbd client, because even if new qemu-nbd > versions will be nice, we shouldn't rely on undefined behaviour. We kno= w > that old qemu-nbd servers won't produce ENOSPC and I'm not sure what > other NBD servers do. Sounds like a plan. > Thanks, that will be helpful in the future. >=20 > Is this the right place to look up the spec? > http://sourceforge.net/p/nbd/code/ci/master/tree/doc/proto.txt Yes. > If so, the commands seem to be hopelessly underspecified, especially > with respect to error conditions. And where it says something about > errors, it doesn't make sense: The server is forbidden to reply to a > NBD_CMD_FLUSH if it failed... (qemu-nbd ignores this, obviously) So does nbd-server. O:-) Looks like you're reading the spec too literally (which is never a bad thing). >> Ok, so it shouldn't reach blk_check_request at all. But then, we shou= ld >> aim at making blk_check_request's checks assertions. >=20 > Sounds fair as a goal, but I don't think all devices have such checks > yet. We've fixed the most common devices (IDE, scsi-disk and virtio-blk= ) > just a while ago. Indeed ("aim at"). Paolo