From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anBCl-0001Iz-UH for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:34:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anBCh-00049A-TU for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:34:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anBCh-00048m-M2 for qemu-devel@nongnu.org; Mon, 04 Apr 2016 16:34:31 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <7AD0DCB1-1868-4AAD-A03D-C976A728DD75@alex.org.uk> <5702C1AB.8020601@redhat.com> <5702C65A.7040101@openvz.org> <48C4F50D-E826-40E7-BB4F-21F9D1A67386@alex.org.uk> <5702C9BE.8050307@openvz.org> From: Eric Blake Message-ID: <5702CFD2.9070402@redhat.com> Date: Mon, 4 Apr 2016 14:34:26 -0600 MIME-Version: 1.0 In-Reply-To: <5702C9BE.8050307@openvz.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eMuTuSJoj8J2qPAo2Jsq2CGKDkqbxAXDe" Subject: Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" , Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , Kevin Wolf , "qemu-devel@nongnu.org" , Pavel Borzenkov , "Stefan stefanha@redhat. com" , Wouter Verhelst , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eMuTuSJoj8J2qPAo2Jsq2CGKDkqbxAXDe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/04/2016 02:08 PM, Denis V. Lunev wrote: >> >> This again makes me think this should be a different >> command from something which is obviously useful and >> comprehensible to more than one server/client (i.e. >> allocation). >> > original design of this command has used 16 number > to specify the NUMBER of the bitmap which was > exported by the server. The original design abused the 16-bit 'flags' field of each command to instead try and treat that value as a bitmap number, instead of a bitwise-or'd set of flags. That was one of the complaints against v1, and was fixed in v2 by having a single boolean flag, NBD_CMD_FLAG_DIRTY, which was off for (default) allocation queries, and set for dirtiness queries. We can add other flags for any other type of queries, and the principle of each query being a run-length-encoded listing still applies.= >=20 > We have reserved number 0 for 'used' bitmap, i.e. > bitmap of allocated blocks and number 1 for 'dirty' > bitmap. Though we can skip specification of the > belonging of any number except '0' and put them > to server-client negotiations. Or we could reserve > '1' for dirtiness state as server-client agrees and > allow other applications to register their own bitmaps > as the deserve to. >=20 > Why not to do things this original way? If you want to encode particular ids, you should do so in a separate field, and not overload the 'flags' field. As it is, we don't have structured writes - right now, you can write a wire sniffer for the client side, where all commands except NBD_CMD_WRITE are fixed size, and NBD_CMD_WRITE describes its own size via its length field; the extension NBD_CMD_WRITE_ZEROES still fits into this scheme. All NBD implementations have to supply NBD_CMD_WRITE, but any extension commands do NOT have to be universal. Writing a wire sniffer that special-cases NBD_CMD_WRITE is easy (since that command will always exist), but writing a wire sniffer that special-cases arbitrary commands, particularly where those arbitrary commands do not also self-describe the length of the command, is hard. We can't overload the flags field to say which bitmap id to grab, but we also can't arbitrarily add 4 bytes to the command size when the command is NBD_CMD_BLOCK_STATUS (because wire sniffers that don't know about NBD_CMD_BLOCK_STATUS wouldn't know to expect those four bytes to be part of the current packet rather than starting a new packet). The recent work on structured reads made it possible for an arbitrary wire sniffer to gracefully skip over the variable-length return size reply to NBD_CMD_BLOCK_STATUS, and any other extension command that we might add later. But right now, I'm not seeing a compelling reason to add structured commands to the NBD protocol. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --eMuTuSJoj8J2qPAo2Jsq2CGKDkqbxAXDe 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/ iQEcBAEBCAAGBQJXAs/SAAoJEKeha0olJ0Nq1QoH/iLpTNH2phXX/Oj+sMLPvE32 rmkgAcO0rgsEB1Ufwty89N1gFHgziQSjcNBV5xfQbfM0kJzUijB+e9Rwmcg2FUME MsZ9g4kJBf/Lc9uPZNPdU1SMcR/cg+8PDbqs/uxtfs9hQ57MBV024T2RpJLtljQv 0HOxYQatNBQW208pzibJnx5RG3Hb0Qmj2id2BrLye8k37qQtOD38doOzZ6BsJ9y2 EJ5xOtbEOFPMVcYfQ8l1MahPXC/5xHzgIt4a9t8j0d70J9fE7L1n9eKtdqPV9p/J Yzw0bhZlIlw+25apZWhftjRq4jMvqT4cPUvnefU3OOh7NuHI880mQIG4TDIX0rg= =p/8+ -----END PGP SIGNATURE----- --eMuTuSJoj8J2qPAo2Jsq2CGKDkqbxAXDe--