> > 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.
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.
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.
--
Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
