Re: Simplified protocol?
On Thu, Nov 15, 2018 at 11:01:57AM -0600, Eric Blake wrote:
> 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).
Hrm, that's much more recent than I thought; but regardless, most
implementations do support OPT_GO nowadays, so OPT_EXPORT_NAME really is
only necessary for backcompat
[...]
> > 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).
Ah, yes, of course; I was looking at things from the client's side, but
you're right, that doesn't matter at all.
Hrm.
> 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.
Yeah, indeed. I'll rewrite things that way, and will send an updated
patch.
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Reply to: