Re: NBD extended (or structured?) request
On 2/4/20 7:01 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
There are some ideas, which needs extra arguments in NBD request:
1. Selecting metacontext for NBD_BLOCK_STATUS [Nir], possibly through new
command, instead of extending the original [Wouter]
2. 64bit block-status/write-zeroes [I know about Eric's work on all-zero
check,
but I think, that 32bit is too restrictive for data-less commands anyway,
skipping and fast-zeroing larger chunks would be profitable in different
scenarios)
I imagine two possibilities:
1. Just new request magic, negotiated by server flag, with structure like
64bits magic
32bits command
64bits handle
32bits length of payload
* payload
Here's previous discussion on adding 64-bit commands, where we could
also work this in:
https://lists.debian.org/nbd/2018/09/msg00001.html
We definitely need a new magic number for clients to let the server know
it is sending a structured request, as well as handshaking (the server
must advertise support for structured requests before a client can send
them). Similar to structured replies, we should require that all
structured requests include a payload length in addition to any length
parameter for the portion of the image the request is related to.
2. Or we can go further, and just take existing structured reply, allowing
requests with same semantics. We even can reuse the magic (but of course
need
new server negotiation flag)
Remember that structured reply chunk has structure:
32bits magic
16bits flags
16bits type
64bits handle
32bits length of payload
* payload
Even if we reuse the structured reply magic for structured requests, it
still looks like a new magic number for requests, and you are correct
that it requires proper handshaking before either side can use the
extension.
And then, on command may consist from several chunks, the last one must
contain
flag NBD_REPLY_FLAG_DONE (hmm, we'll need to rename it to just
NBD_STRUCTURED_CHUNK_FLAG_DONE). I think, that server even may start to
reply
(send some structured reply chunks) before collecting all request chunks :)
This will also make possible to implement structured write, which may be
useful
in a scenario, when we read from one NBD and write to another, we can keep
structured read result and pass it directly to structured write.
===
Then, we can add extended commands, like NBD_CMD_WRITE_ZEROES_64, with
8-bytes
payload:
64bits offset
64bits length
We can add 32bits or 16bits flags here, or we can use flags field of the
structured chunk, to store some command flags.
We can use same flags/type for this NBD_CMD_WRITE_ZEROES_64 as for
NBD_CMD_WRITE_ZEROES, or use new type.
Also, it's a question, should it be considered as absolutely new
command, or
maybe better to alter existing description of NBD_CMD_WRITE_ZEROES to
support
64bit feature.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Reply to: