From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anBzk-0007Xv-Fc for qemu-devel@nongnu.org; Mon, 04 Apr 2016 17:25:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anBzf-0006sy-F5 for qemu-devel@nongnu.org; Mon, 04 Apr 2016 17:25:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anBzf-0006sf-8C for qemu-devel@nongnu.org; Mon, 04 Apr 2016 17:25:07 -0400 References: <1459787950-15286-1-git-send-email-eblake@redhat.com> <7AD0DCB1-1868-4AAD-A03D-C976A728DD75@alex.org.uk> <5702C1AB.8020601@redhat.com> <5702C8C3.1050300@openvz.org> <5702CDE8.6000805@redhat.com> From: Eric Blake Message-ID: <5702DBAF.40109@redhat.com> Date: Mon, 4 Apr 2016 15:25:03 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="coIaNXDMCe2r62uIhFGNNFpd5xPsBVTx0" 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: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , Kevin Wolf , "qemu-devel@nongnu.org" , Pavel Borzenkov , "Stefan stefanha@redhat. com" , Paolo Bonzini , Wouter Verhelst , "Denis V. Lunev" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --coIaNXDMCe2r62uIhFGNNFpd5xPsBVTx0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/04/2016 03:07 PM, Alex Bligh wrote: >=20 > On 4 Apr 2016, at 21:26, Eric Blake wrote: >=20 >> Huh? The current proposal _requires_ these to be separate queries. Yo= u >> cannot query dirtiness at the same time as allocation, because the val= ue >> of NBD_CMD_FLAG_DIRTY is distinct between the two queries. >=20 > OK, so you can ask for either (1) or (2), but not both. I see. I misrea= d > that. I still think Denis's idea of selecting a bitmap to query works b= etter. I'm still not sure I follow what you are proposing in 'selecting a bitmap', at least not without also needing to expand the protocol to allow for a structured command that has more than a fixed-length message size (currently all commands except NBD_CMD_WRITE) or a self-described size (NBD_CMD_WRITE). Would this bitmap id be specified as an integer (32 bits?) as an arbitrary UTF-8 string? or as something else? And since we _already_ documented that querying dirty information requires out-of-band coordination, why can't the out-of-band communication convey the bitmap selection, so that the NBD command then just reads the dirty status of the already-selected bitmap? It was Paolo's suggestion to document that querying dirty status is only useful with out-of-band coordination, at which point, why bloat the NBD protocol with details that are better left to that external coordination? Wouter had a valid complaint that v1 was unspecified (it said that being "dirty" was implementation defined, but gave no other meaning and a server could use random numbers and still be compliant); v2 picked up Paolo's wording suggestion against v1 that tries to make it obvious that being "dirty" is still implementation defined, but that the definition is whatever it takes for a coordination with out-of-band information to provide useful results. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --coIaNXDMCe2r62uIhFGNNFpd5xPsBVTx0 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/ iQEcBAEBCAAGBQJXAtuvAAoJEKeha0olJ0Nqu90H/A/zWLaGMNVxOwzpoauMRCVS veBXaNAo4JTNXYaz+SsV+HX6AR6n8OHVN1ugYaEX0Awni0v0X9B16IS5JHshF7AW I/MkwsqJWTptUx+Pz21dzDdp7LiKAPlRFEOLjmCuoRg2qUSpke+GYAO5v++1ihgT RTqiTVyHdRPjBjnTiHp6GCXOgTDybWabDPgrDHLi/bANVx0WtDVHT2sdKE+RLto0 u3VCfZM8RhAcRZw73dN2zF0cGn/PVUZkaL6YWsQRHvI23zeTQ6yd8E9vx3FVUdXK qYpOxgvEm+D2u/yp3BZlhb7qrimQv2banaNyzjygx1u0/BTnHmy1/XM0Hcgb/XI= =lJvF -----END PGP SIGNATURE----- --coIaNXDMCe2r62uIhFGNNFpd5xPsBVTx0--