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, implementationss/1024/512/Actually, nbd-client defaults to 1024, and has done that for a *long* time :-)
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