Displaying 7 results from an estimated 7 matches for "nbd_opt_extended_head".
2023 Aug 03
1
[libnbd PATCH v4 20/25] generator: Actually request 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
a...
2023 Mar 03
1
[PATCH v2 3/6] spec: Add NBD_OPT_EXTENDED_HEADERS
..., 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_INVALI...
2022 Nov 14
2
[PATCH v2 3/6] spec: Add NBD_OPT_EXTENDED_HEADERS
...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 repl...
2023 Apr 13
6
[PATCH v3 0/6] NBD 64-bit extensions (spec only)
...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...
2023 Mar 03
1
[PATCH v2 5/6] spec: Introduce NBD_FLAG_BLOCK_STATUS_PAYLOAD
...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_BLOC...
2023 Apr 13
2
[PATCH v3 6/6] RFC: spec: Introduce NBD_REPLY_TYPE_OFFSET_HOLE_EXT
...+ 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 leng...
2022 Nov 14
3
[cross-project PATCH v2] NBD 64-bit extensions
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