From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCoS3-0004je-P2 for qemu-devel@nongnu.org; Tue, 14 Jun 2016 09:32:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCoS1-0005qi-Rc for qemu-devel@nongnu.org; Tue, 14 Jun 2016 09:32:18 -0400 References: <1463006384-7734-1-git-send-email-eblake@redhat.com> <1463006384-7734-5-git-send-email-eblake@redhat.com> <852e526a-5235-499a-741e-a695f5e74f83@redhat.com> <575EA656.80508@redhat.com> <6DD06745-C91C-4BFB-BFE5-92E5982ACB42@alex.org.uk> From: Paolo Bonzini Message-ID: <11f620d2-a51d-5235-5abd-4ced314c9090@redhat.com> Date: Tue, 14 Jun 2016 15:32:06 +0200 MIME-Version: 1.0 In-Reply-To: <6DD06745-C91C-4BFB-BFE5-92E5982ACB42@alex.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 04/11] nbd: Improve server handling of bogus commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh , Eric Blake Cc: "qemu-devel@nongnu.org" , qemu-block@nongnu.org, "nbd-general@lists.sourceforge.net" On 13/06/2016 23:41, Alex Bligh wrote: > That's one of the reasons that there is a proposal to add > STRUCTURED_READ to the spec (although I still haven't had time to > implement that for qemu), so that we have a newer approach that allows > for proper error handling without ambiguity on whether bogus bytes must > be sent on a failed read. But you'd have to convince me that ALL > existing NBD server and client implementations expect to handle a read > error without read payload, otherwise, I will stick with the notion tha= t > the current spec wording is correct, and that read errors CANNOT be > gracefully recovered from unless BOTH sides transfer (possibly bogus) > bytes along with the error message, and which is why BOTH sides of the > protocol are warned that read errors usually result in a disconnection > rather than clean continuation, without the addition of STRUCTURED_READ= . I suspect that there are exactly two client implementations, namely Linux and QEMU's, and both do the right thing. What servers do doesn't matter, if all the clients agree. Paolo