From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alzs9-0007on-Nb for qemu-devel@nongnu.org; Fri, 01 Apr 2016 10:16:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alzs4-0007MY-OA for qemu-devel@nongnu.org; Fri, 01 Apr 2016 10:16:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alzs4-0007MN-GO for qemu-devel@nongnu.org; Fri, 01 Apr 2016 10:16:20 -0400 References: <56FD7B7E.4060004@redhat.com> <64B326DA-CDF4-4537-B38A-46E7B57C319C@alex.org.uk> <56FD8069.7020101@redhat.com> <56FD89D0.5050408@redhat.com> <20160401082715.GB25514@grep.be> From: Eric Blake Message-ID: <56FE82B3.4010205@redhat.com> Date: Fri, 1 Apr 2016 08:16:19 -0600 MIME-Version: 1.0 In-Reply-To: <20160401082715.GB25514@grep.be> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hdt9pjQFpx8KMnAUNxXO7NISvrs4FbOs2" Subject: Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , Alex Bligh This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hdt9pjQFpx8KMnAUNxXO7NISvrs4FbOs2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/2016 02:27 AM, Wouter Verhelst wrote: > That's what I'm mostly worried about. Yes, we have FUA, and yes, some > clients may send it on commands that aren't WRITE, but it is not very > well defined what happens then: >=20 > - Currently-released versions of nbd-server will accept the flag on > non-WRITE commands, but ignore it. This is generally not desirable, I= > would say. > - The change that I made a few days ago means future versions will *not= * > accept it. I feel this is better than accepting-and-ignoring, but not= > ideal either in case a client sends out a request that includes FUA. >=20 We have not yet released any version of the server that rejects FUA on a command, so that may work in our favor with my strawman below (but does mean we need to relax your recent commit before releasing). > We can perhaps ignore the former of the above as "buggy behaviour" and > not negotiate anything for a server that does the "proper" thing of > accepting-and-acting-on for non-WRITE FUA, but then it is probably a > good idea to document in the spec that "there are older, buggy, servers= > which accept but ignore FUA on anything but WRITE", at least for a few > years until such older servers aren't available anymore. >=20 > Alternatively, we could add yet another flag bit to signal "FUA valid > everywhere". Not sure if that is worth it. Or rather than a flag bit, what about this strawman: NBD_FLAG_SEND_FUA: If set, the server understands the NBD_CMD_FLAG_FUA bit. Except where more specific mandatory or optional behavior is documented on a given request, the server MUST ignore NBD_CMD_FLAG_FUA if it advertised NBD_FLAG_SEND_FUA. Clients SHOULD NOT assume that the flag will have an effect on anything other than NBD_CMD_WRITE, unless the client has first checked NBD_OPT_QUERY_FUA. If clear, the client MUST NOT use NBD_CMD_FLAG_FUA. NBD_OPT_QUERY_FUA Data: 16 bits, the request type to check Responses: - NBD_REP_ACK - If NBD_CMD_FLAG_FUA is set for the given request type, the server obeys FUA semantics as documented for that command. If the server will be advertising NBD_FLAG_SEND_FUA, then it MUST use this reply for NBD_CMD_WRITE, and SHOULD use this reply for all other supported request types that have documented mandatory behavior for NBD_CMD_FLAG_FUA. - NBD_REP_ERR_POLICY - The server knows the request type, but either the server will not be advertising NBD_FLAG_SEND_FUA, or the server will ignore the NBD_CMD_FLAG_FUA flag; either way, the client SHOULD NOT use NBD_CMD_FLAG_FUA with a request of this type. The server SHOULD use this reply for request types that have documented optional behavior for NBD_CMD_FLAG_FUA where the server did not implement that optional behavior (such as NBD_CMD_TRIM), and for commands that do not specify behavior (such as NBD_CMD_DISC). - NBD_REP_ERR_INVALID - The server does not recognize the request type in question. The server MUST use this reply for request types that it does not know (including for NBD_CMD_WRITE_ZEROES if the server will not be advertising NBD_FLAG_SEND_WRITE_ZEROES). - For backward compatibility, the client should also be prepared for NBD_REP_ERR_UNSUP, when the server does not understand the option request, and the client SHOULD assume that NBD_CMD_FLAG_FUA will be honored for NBD_CMD_WRITE if NBD_FLAG_SEND_FUA is advertised, and SHOULD NOT use NBD_CMD_FLAG_FUA on any other request. NBD_CMD_WRITE: If NBD_FLAG_SEND_FUA is set, the server MUST obey FUA semantics. NBD_CMD_WRITE_ZEROES: If NBD_FLAG_SEND_FUA is set and the write zeroes extension is advertised, the server MUST obey FUA semantics. NBD_CMD_READ: If NBD_FLAG_SEND_FUA is set, the client SHOULD use NBD_OPT_QUERY_FUA to determine whether using NBD_CMD_FLAG_FUA will have any effect; the server SHOULD obey FUA semantics (if we figure out what they are!), but buggy servers MAY ignore the flag instead. NBD_CMD_FLUSH: If NBD_FLAG_SEND_FUA is set, the client SHOULD use NBD_OPT_QUERY_FUA to determine whether using NBD_CMD_FLAG_FUA will have any effect; the server SHOULD obey FUA semantics, but buggy servers MAY ignore the flag instead. NBD_CMD_TRIM: If NBD_FLAG_SEND_FUA is set, the client SHOULD use NBD_OPT_QUERY_FUA to determine whether using NBD_CMD_FLAG_FUA will have any effect. Since the command is advisory, the server is free to ignore the flag. Thoughts? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --hdt9pjQFpx8KMnAUNxXO7NISvrs4FbOs2 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/oKzAAoJEKeha0olJ0NqLJMIAIVa7LpGmsbBUMQ2AadUeBGR W1XzRax4cCcnBp8wl8lQorxZzZsOU9UeGIInlSUSTMRX7XpSbjhVt4jwovrhBTd2 bqviE1LKAlxaZf7NbDzJk5Nj+VX/DyARcikbVH8cCiY6tIjrplKLPCTP2LYtZvDc HL82d/paeJ0Ko4GU2f2HqsKh736MC+QwUoQcUATD8qmnz7H2Q2qBxqNE2KJ6Vy2k XiGGtcpHTXPOD0fvc/vVffelQfSCk7VoaUN4UAxML/B7xKocKvQhur0EjALTYYBn Yiks6l59LYwS65hF1bTU+0K8MgRfJEqZh9BtfxTUKm0h/aB2G+3oZeHUvnCTQ+M= =AoSN -----END PGP SIGNATURE----- --hdt9pjQFpx8KMnAUNxXO7NISvrs4FbOs2--