From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am0gq-00013Y-5t for qemu-devel@nongnu.org; Fri, 01 Apr 2016 11:08:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1am0gk-00021a-Cn for qemu-devel@nongnu.org; Fri, 01 Apr 2016 11:08:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am0gk-00021V-5N for qemu-devel@nongnu.org; Fri, 01 Apr 2016 11:08:42 -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> <56FE82B3.4010205@redhat.com> <33E7C614-E8C4-48FF-84BE-7F2418C65D22@alex.org.uk> From: Eric Blake Message-ID: <56FE8EF8.3080603@redhat.com> Date: Fri, 1 Apr 2016 09:08:40 -0600 MIME-Version: 1.0 In-Reply-To: <33E7C614-E8C4-48FF-84BE-7F2418C65D22@alex.org.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Cnhlw78kKwQQXPmigkPvtNDHdiJtbBb2p" 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: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , Wouter Verhelst , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cnhlw78kKwQQXPmigkPvtNDHdiJtbBb2p Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/2016 09:00 AM, Alex Bligh wrote: >> >> 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 th= e >> flag will have an effect on anything other than NBD_CMD_WRITE, unless >=20 > and NBD_CMD_WRITE_ZEROES presumably >=20 >> 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: > ... >> Thoughts? >=20 > A bit overengineered I think. I can't realistically see clients writing= > code that would negotiate all that. Fair enough. I was just throwing it out there so that at least we considered our tradeoffs. >=20 > Personally I think we should stick to: >=20 > * Don't send FUA unless NBD_FLAG_SEND_FUA is set >=20 > * FUA works on NBD_CMD_WRITE and NBD_CMD_WRITE_ZEROES >=20 > * On all the other commands: >=20 > - If it does anything in the linux kernel, we should make > it do the same thing here. (We know it doesn't for Qemu > or rather Qemu doesn't rely on it) >=20 > - If it does not do anything in the linux kernel, then we > should decide whether we want to: do > a) client SHOULD NOT send, server MUST ignore it (my preference) > or > b) client MUST NOT send, server MUST close connection. closing the connection is not strictly necessary (except maybe for NBD_CMD_READ without structured replies); for all other commands, the server may reply with EINVAL error instead of closing the connection. But yes, I'm favoring a) as well, for the simplicity factor. There's still the issue that if we document a behavior, a new client talking to an older server can't reliably tell if the behavior will be guaranteed. > I suppose I am going have to try another lkml message to get > to the bottom of the first one. On the other hand if we > take route (a) above, we can relatively easily add a > 'meaning' later as people can't have been relying on it > working. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Cnhlw78kKwQQXPmigkPvtNDHdiJtbBb2p 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/o74AAoJEKeha0olJ0NqfzQH+gNn8FWwUPI+9G5qDAOYzwme OVoD1JbhDwmmrbDOm3zb/fw+M1c3Dak6mEOkoWJcGVYyRVjrx0k79rX09JPD45zd CylofKWr3YylU/S3kioAumzDyKo3M4nlkZBiHULvD5+2o5AU2h7v72bqWVp5c3uV rPO7wMklRXUv6NnuRPl4HWfZoAOOvhF6E89u2Se35l6y7XQ//i/+zcFzlMR6CkPb 8DXhVKNZlFkUdhA+OS9s7mF/fGqusmwTNBEkpjUKErFD9vUT89v5iUbnkpQLZVgY 8eL/knQ/Pjm7tRBMMEytuOVjx3B4K82joa7JG6EdHDmK9MIO6sqWdIIyXmlckXs= =K+qE -----END PGP SIGNATURE----- --Cnhlw78kKwQQXPmigkPvtNDHdiJtbBb2p--