[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: Let NBD client request read-only mode

From: Eric Blake
Subject: Re: [Qemu-devel] RFC: Let NBD client request read-only mode
Date: Thu, 30 Nov 2017 10:00:46 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/30/2017 09:32 AM, Wouter Verhelst wrote:

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.


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

There's also the question of inconsistent reads - normally, if a client is the only reader, the client can cache data rather than having to re-read it from the server; whereas if there is another writer in parallel, the client SHOULD read data again rather than relying on the cache (since the other writer may have changed data in the meantime) - so maybe having a way for the server to report whether reads may be inconsistent, or even give an error to NBD_OPT_GO unless the client requests (via NBD_OPT_READ_ONLY or some other way) that the client is aware of the potential for volatile/inconsistent reads.

I think it sounds reasonable enough, yes; but I also think there are a
few other related situations that might be relevant enough to warrant
thinking about more. I gave a few examples above, but maybe there are
more? Dunno.

Okay, sounds like it warrants enough potential for conversation that I should write it up as a patch, and the patch may need a new extension- branch rather than going straight into mainline; and I'll stick with idea 2 (NBD_OPT_READ_ONLY) rather than burning a global handshake bit. I hope to give the documentation patch a shot in the next few days.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]