From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aku6K-0000so-Qz for qemu-devel@nongnu.org; Tue, 29 Mar 2016 09:54:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aku6G-0006dJ-HS for qemu-devel@nongnu.org; Tue, 29 Mar 2016 09:54:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aku6G-0006dD-CK for qemu-devel@nongnu.org; Tue, 29 Mar 2016 09:54:28 -0400 References: <1459161798-32120-1-git-send-email-den@openvz.org> <1459161798-32120-2-git-send-email-den@openvz.org> <56F92AE1.2040709@redhat.com> <20160329072223.GB22386@grep.be> From: Eric Blake Message-ID: <56FA8912.90207@redhat.com> Date: Tue, 29 Mar 2016 07:54:26 -0600 MIME-Version: 1.0 In-Reply-To: <20160329072223.GB22386@grep.be> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AXXWxcqhmCjFHvBbdWa5kQfPUBnConRio" Subject: Re: [Qemu-devel] [Nbd] [PATCH 1/3] NBD proto: forbid TRIM command without negotiation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst Cc: nbd-general@lists.sourceforge.net, "Denis V. Lunev" , qemu-devel@nongnu.org, Pavel Borzenkov This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AXXWxcqhmCjFHvBbdWa5kQfPUBnConRio Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2016 01:22 AM, Wouter Verhelst wrote: >>> +++ b/doc/proto.md >>> @@ -471,6 +471,9 @@ The following request types exist: >>> about the contents of the export affected by this command, until= >>> overwriting it again with `NBD_CMD_WRITE`. >>> =20 >>> + A client MUST NOT send a trim request unless `NBD_FLAG_SEND_TRIM= ` >>> + was set in the export flags field. >>> + >> >> Do we also want to mention that the server SHOULD fail with EINVAL if >> the client sends it anyway, and similarly if NBD_CMD_FLUSH was sent >> without the appropriate export flag (but that the client should not re= ly >> on that particular failure)? >=20 > I think the protocol should mention that the server MAY fail with > EINVAL, rather than SHOULD. Rationale: the robusness principle -- if yo= u > didn't negotiate it, you may end up with a server who doesn't know abou= t > the feature; but if it just so happens that the server does know about = it even > though you didn't negotiate it, there is little harm in it following up= on the > request. Good point; furthermore, a server is compliant if it accepts and ignores NBD_CMD_TRIM (as that command is only a hint); which is different from NBD_CMD_FLUSH (which must ensure a barrier). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --AXXWxcqhmCjFHvBbdWa5kQfPUBnConRio 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/ iQEcBAEBCAAGBQJW+okSAAoJEKeha0olJ0NqgG4H/jwX94BRjRcgCM4VYjOXN6fE oD4wdV2UTXKOyD1z98vk99QIIVGYr/gkPobSQ1Wa1Ryjk7ymC+5w6sDQkb29+rU1 qmKXZwrmiUvEUcjNs6/Ua7bTWKd2zhPmy/jSISVpmW9pxyy0gOVTU06NR+AQ6iLC rAk2HzK0qeRbpNFwOgYcAniRFVd/fHKipsNL4YMQajT4iCb8pV2Bj1Uogo9jZjTL fI1jQGqnAkGjqTz5w3dmTb/NCKz3jmWoruB92D/3ObEqzn6RxleAzWXb8R6E0uL5 15X8yBlnSC6p+S14ZfP8KLTa+ThWtweBh9K6eh67hG1F/G2vrLvZwhBb9ZahpCw= =gpSk -----END PGP SIGNATURE----- --AXXWxcqhmCjFHvBbdWa5kQfPUBnConRio--