From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6dY-0006Pj-PQ for qemu-devel@nongnu.org; Thu, 24 Mar 2016 10:53:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj6dV-0005pa-J7 for qemu-devel@nongnu.org; Thu, 24 Mar 2016 10:53:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6dV-0005pM-C1 for qemu-devel@nongnu.org; Thu, 24 Mar 2016 10:53:21 -0400 References: <1458742562-30624-1-git-send-email-den@openvz.org> <1458742562-30624-2-git-send-email-den@openvz.org> <20160323172116.GA2467@grep.be> <20160324075706.GA24831@phobos.sw.ru> <20160324082641.GF1590@grep.be> From: Eric Blake Message-ID: <56F3FF5F.2010109@redhat.com> Date: Thu, 24 Mar 2016 08:53:19 -0600 MIME-Version: 1.0 In-Reply-To: <20160324082641.GF1590@grep.be> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7ODPPWaemBReT7f32vuTwt4Q3VutxPdMD" Subject: Re: [Qemu-devel] [Nbd] [PATCH 1/2] NBD proto: add WRITE_ZEROES extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst , Pavel Borzenkov Cc: nbd-general@lists.sourceforge.net, Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini , "Denis V. Lunev" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7ODPPWaemBReT7f32vuTwt4Q3VutxPdMD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/24/2016 02:26 AM, Wouter Verhelst wrote: >> No, there is no specific reason. Looks like NBD_CMD_FLAG_ZEROES fits t= he >> spec and implementations nicely. So I'll rewrite the extension and add= >> the flag instead of the whole command. >=20 > Actually, having given this some more thought... >=20 > There is at least one server-side implementation of nbd (mine) which > silently ignores flags it doesn't know about. This isn't a problem for > non-critical flags, but it could be a problem for a flag like this. Of > course, a client shouldn't send a flag to a server which that server > hasn't heard of, but mistakes do happen. This is the first time where the presence or absence of a flag would determine whether the length of the payload should be 0 bytes or len bytes. If the server doesn't recognize the flag, then it will try to read the next length bytes off the wire as the data to write, rather than as the next command to process. >=20 > Do we want to keep that in mind? If so, we might want to keep it as a > separate command after all. >=20 > OTOH, it could be said that silently ignoring unknown messages is a bug= =2E > I should probably just fix my implementation instead. While I agree that you should fix your implementation, I am strongly in favor of a new command, so that we can blindly state that the NBD_CMD_WRITE always sends a payload of length bytes, independent of flag value. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --7ODPPWaemBReT7f32vuTwt4Q3VutxPdMD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJW8/9fAAoJEKeha0olJ0NqP0YH/3ApHPLTtx+f6LgSAjxtrTxw v5t66vK1FCguPLD0R9DgTFjM64gBTorOX28V0RniavjWWaLp0agFfL58uRmCaZ4H bECQOTd0glJoRq9816FGZv/N7+xeo9wA+yt964SUiLptBaG89hEbX3D5KH45v65S beAMyyD/SAZxlv0i5lcW1Ez5CNb1I2xnlIEgH0ZcYI1Ie8nm2QCmHnFSmEXp/sBj Yn5eC4BwLLUNaEdzYIZBMEIzME8vA5BMC9xdEQLSDuRZUtrDYY0cPcC5phSXwcT0 n4AwRM9eZpQCJLtQot0F7JhdwCz2b45fZc+Kew7aZlxmUUjhFErofvd2DlzwVKI= =0UqF -----END PGP SIGNATURE----- --7ODPPWaemBReT7f32vuTwt4Q3VutxPdMD--