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: 2384 bytes --]

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 the
>> flag will have an effect on anything other than NBD_CMD_WRITE, unless
> 
> and NBD_CMD_WRITE_ZEROES presumably
> 
>> 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?
> 
> 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.

> 
> Personally I think we should stick to:
> 
> * Don't send FUA unless NBD_FLAG_SEND_FUA is set
> 
> * FUA works on NBD_CMD_WRITE and NBD_CMD_WRITE_ZEROES
> 
> * On all the other commands:
> 
>   - 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)
> 
>   - 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.

-- 
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 --]