[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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:


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
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: