Tags: NetworkBlockDevice/nbd
Tags
RFC: spec: Introduce NBD_REPLY_TYPE_OFFSET_HOLE_EXT Rather than requiring all servers and clients to have a 32-bit limit on maximum NBD_CMD_READ/WRITE sizes, we can choose to standardize support for a 64-bit single I/O transaction now. NBD_REPLY_TYPE_OFFSET_DATA can already handle a large reply, but NBD_REPLY_TYPE_OFFSET_HOLE needs a 64-bit counterpart. By standardizing this, all clients must be prepared to support both types of hole type replies, even though most server implementations of extended replies are likely to only send one hole type. --- As this may mean a corner-case that gets less testing, I have separated it into a separate optional patch. I implemented it in my proof-of-concept, but am happy to drop this patch for what actually goes upstream. In particular, if we foresee clients and servers that WANT to support a payload larger than 4G, it may be worth introducing an NBD_INFO_* that supplies 64-bit block sizing information, rather than our current inherent 32-bit limit of NBD_INFO_BLOCK_SIZE, at the same time as we introduce this reply type.
Tagging NBD 1:3.21-1 for Debian This should've been done when we released it, but we forgot, so do it now.
Tagging NBD for Debian 1:3.19-3 Forgot that at release time
spec: Add NBD_OPT_EXTENDED_HEADERS Add a new negotiation feature where the client and server agree to use larger packet headers on every packet sent during transmission phase. This has two purposes: first, it makes it possible to perform operations like trim, write zeroes, and block status on more than 2^32 bytes in a single command; this in turn requires that some structured replies from the server also be extended to match. The wording chosen here is careful to permit a server to use either flavor in its reply (that is, a request less than 32-bits can trigger an extended reply, and conversely a request larger than 32-bits can trigger a compact reply). Second, when structured replies are active, clients have to deal with the difference between 16- and 20-byte headers of simple vs. structured replies, which impacts performance if the client must perform multiple syscalls to first read the magic before knowing how many additional bytes to read. In extended header mode, all headers are the same width, so the client can read a full header before deciding whether the header describes a simple or structured reply. Similarly, by having extended mode use a power-of-2 sizing, it becomes easier to manipulate headers within a single cache line, even if it requires padding bytes sent over the wire. However, note that this change only affects the headers; as data payloads can still be unaligned (for example, a client performing 1-byte reads or writes), we would need to negotiate yet another extension if we wanted to ensure that all NBD transmission packets started on an 8-byte boundary after option haggling has completed. This spec addition was done in parallel with a proof of concept implementation in qemu (server and client) and libnbd (client), and I also have plans to implement it in nbdkit (server). Signed-off-by: Eric Blake <eblake@redhat.com>
PreviousNext