A client that wants to be read-only, but which does not see server support
(in idea 1, the server did not advertise the bit; in idea 2, the server
replies with NBD_REP_ERR_UNSUP), does not have to do anything special (it is
always possible to do just reads to a read-write connection, and the server
may still set NBD_FLAG_READ_ONLY even without supporting the extension of
permitting a client-side request). But such a client may, if it wants to be
nice to potential parallel writers on the same export, decide to disconnect
quickly (with NBD_OPT_ABORT or NBD_CMD_DISC as appropriate) rather than tie
up a read-write connection.
Indeed.
I don't know which idea is more palatable. We have a finite set of only 2^4
global handshake flags because it is a bitmask, where only 14 bits remain;
whereas we have almost 2^32 potential NBD_OPT_ values. On the other hand,
using a global handshake flag means the server never shows any export as
writable; while with the NBD_OPT_ solution, a guest can get different
results for the sequence NBD_OPT_INFO, NBD_OPT_READ_ONLY, NBD_OPT_INFO.
It might additionally also be a good idea to add another data item to
the NBD_OPT_INFO response which tells the client that it will be the
only writer, but that there may be other readers.
That way, if a client sees that data item, it could go "oh, but I don't
need to write -- here's an NBD_OPT_READ_ONLY for you".