Re: Simplified protocol?
On 11/15/18 9:23 AM, Wouter Verhelst wrote:
On Thu, Nov 15, 2018 at 08:59:56AM -0600, Eric Blake wrote:
On 11/15/18 8:41 AM, Wouter Verhelst wrote:
+ - the `NBD_OPT_INFO` and `NBD_OPT_GO` messages, with the
+ `NBD_INFO_EXPORT` response.
Of the required items, this is probably the most recent addition to the
standard (and therefore the most likely to be missing from older
implementations); should we mention that clients should be prepared to fall
back to NBD_OPT_EXPORT_NAME, or are we sufficiently long enough into the
existence of this addition (and with multiple implementations that DO
support it) to now make it mandatory?
My train of thought was something along the latter lines, yes. Even so,
I do mention the fact that NBD_OPT_EXPORT_NAME is necessary for older
implementations in the "maximum interoperability" section. I think
that's a reasonable tradeoff, but don't feel too strongly about it; if
others disagree, I'm happy to move OPT_INFO/OPT_GO to "Future
considerations" and mention NBD_OPT_EXPORT_NAME here.
I'm fine either way (nbdkit is the latecomer here, adding NBD_OPT_GO
support only in August 2018).
+ Similarly, clients that desire maximum interoperability SHOULD
+ implement querying for block size constraints. Since some older
+ clients default to a block size of 1024 bytes, implementations
Actually, nbd-client defaults to 1024, and has done that for a *long*
while qemu has defaulted to 512.
That's probably not a good idea, but it is a clean multiple of 512, so
should be fine for these purposes.
The real concern is that any client that asks for data smaller than the
alignment expected by the server forces the server to implement
read-modify-write, which can slow things down, and I don't want
read-modify-write to be mandated as part of the baseline (but rather
left as a quality-of-implementation extension, at which point the server
can advertise a minimum block size of 1). nbd-client grabbing in
multiples of 1024 is not as big a concern as servers unable to handle
requests that are not 512-aligned. But we also have to consider that 4k
sectors are becoming more common, so there's a tradeoff on whether
requiring servers to support 512-byte sectors vs. supporting block size
advertisement should be part of the baseline. Right now, we have enough
clients that use smaller than 4k (nbd-client with 1024, qemu with 512)
that it's probably okay to document that servers should support writes
that small, but the baseline need not require support for anything
smaller than 512.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org