search for: nbd_opt_extended_headers

This is the culmination of the previous patches' preparation work for using extended headers when possible. The new states in the state machine are copied extensively from our handling of OPT_STRUCTURED_REPLY. The next patch will then expose a new API nbd_opt_extended_headers() for manual control. At the same time I posted this patch, I had patches for qemu-nbd to support extended headers as server (nbdkit is a bit tougher). The next patches will add some interop tests that pass when using a new enough qemu-nbd, showing that we have cross-project interoperability and...

..., but our spec already has reasonable constraints that the client should at least recognize it as an error code. That way, a server only has to implement extended headers, rather than maintaining the structured header code in parallel. > > (this occurs twice) > > [...] > > +* `NBD_OPT_EXTENDED_HEADERS` (11) > > + > > + The client wishes to use extended headers during the transmission > > + phase. The client MUST NOT send any additional data with the > > + option, and the server SHOULD reject a request that includes data > > + with `NBD_REP_ERR_INVALID`....

...unk. The +There are two general message types in the transmission phase: the +request (simple or extended), and the reply (simple, structured, or +extended). The determination of which message headers to use is +determined during handshaking phase, based on whether +`NBD_OPT_STRUCTURED_REPLY` or `NBD_OPT_EXTENDED_HEADERS` was requested +by the client and given a successful response by the server. The transmission phase consists of a series of transactions, where the client submits requests and the server sends corresponding replies with either a single simple reply or a series of one or more -structured reply c...

...h is downstream-only The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively 001/6:[----] [-C] 'spec: Recommend cap on NBD_REPLY_TYPE_BLOCK_STATUS length' 002/6:[down] 'spec: Change maximum block size to maximum payload size' 003/6:[0237] [FC] 'spec: Add NBD_OPT_EXTENDED_HEADERS' 004/6:[----] [-C] 'spec: Allow 64-bit block status results' 005/6:[----] [-C] 'spec: Introduce NBD_FLAG_BLOCK_STATUS_PAYLOAD' 006/6:[0062] [FC] 'RFC: spec: Introduce NBD_REPLY_TYPE_OFFSET_HOLE_EXT' Eric Blake (6): spec: Recommend cap on NBD_REPLY_TYPE_BLOCK_STATUS le...

...onse to a specific subset of negotiated > > + metacontext ids passed in via a client payload, rather than the > > + default of replying to all metacontext ids. Servers MUST NOT > > + advertise this bit unless the client successfully negotiates > > + extended headers via `NBD_OPT_EXTENDED_HEADERS`, and SHOULD NOT > > + advertise this bit in response to `NBD_OPT_EXPORT_NAME` or > > + `NBD_OPT_GO` if the client does not negotiate metacontexts with > > + `NBD_OPT_SET_META_CONTEXT`; clients SHOULD NOT set the > > + `NBD_CMD_FLAG_PAYLOAD_LEN` flag for `NBD_CMD_BLOCK_S...

...+ This chunk type is in the content chunk category. *length* MUST be + exactly 16. The semantics of this chunk mirror those of + `NBD_REPLY_TYPE_OFFSET_HOLE`, other than the use of a larger *hole + size* field. This chunk type MUST NOT be used unless extended + headers were negotiated with `NBD_OPT_EXTENDED_HEADERS`. + + The payload is structured as: + + 64 bits: offset (unsigned) + 64 bits: hole size (unsigned, MUST be nonzero) + + Note that even though extended headers are in use, a server may + enforce a maximum effect length on `NBD_CMD_READ` comparable to an + advertised maximum payload length...

This is a cover letter for a set of multi-project patch series all designed to implement 64-bit operations in NBD, and demonstrate interoperability of the new extension between projects. v1 of the project was attempted nearly a year ago: https://lists.nongnu.org/archive/html/qemu-devel/2021-12/msg00453.html Since then, I've addressed a lot of preliminary cleanups in libnbd to make it easier