Re: [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?

[Alex Bligh <alex@...872...>]

On 1 Apr 2016, at 09:27, Wouter Verhelst <w@...112...> wrote:

>> It's also tricky because we just barely documented that servers SHOULD
>> reject invalid flags with EINVAL; and that clients MUST NOT send FUA on
>> commands where it is not documented; I don't know if we have an adequate
>> discovery system in place to learn _which_ commands support FUA,
> 
> 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:

Actually the text says:

> Clients MUST NOT set a command flag bit that is not documented for the particular command; and whether a flag is valid may depend on negotiation during the handshake phase.


So this gives us an easy out. We document NBD_CMD_FLAG_FUA for every command, but say it is meaningless for commands outside some subset (see below), and therefore 'SHOULD NOT' be used by the client. For commands outside that subset, the server SHOULD ignore it. That means that we don't need to change the above text, as it is documented.

However, I'm not clear what the subset of commands NBD_CMD_FLAG_FUA should work on is. I originally thought it was anything that writes. Paolo has pointed out it's pointless for TRIM given it's advisory. It makes sense for anything that writes holes. I am not clear what it should do for reads - the original semantic was meant to be the kernel bio layer semantic, and (as per message to Paolo) the kernel documentation is less than helpful in whether it can be set on a read bio.

-- 
Alex Bligh