Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4574 bytes --]

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:
> 
> - 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.
> 

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.
> 
> 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?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]