diff options
author | Eric Blake <eblake@redhat.com> | 2023-09-25 14:22:35 -0500 |
---|---|---|
committer | Eric Blake <eblake@redhat.com> | 2023-10-05 11:02:08 -0500 |
commit | 9c1d26143764dc53c19d872de4f8a9f820e05177 (patch) | |
tree | a47d804af86596ed5d442061e8917a1cf49930a7 /docs | |
parent | bcc16cc19eb87889c92b71a8cde77f502e7e19be (diff) |
nbd/server: Enable initial support for extended headers
Time to start supporting clients that request extended headers. Now
we can finally reach the code added across several previous patches.
Even though the NBD spec has been altered to allow us to accept
NBD_CMD_READ larger than the max payload size (provided our response
is a hole or broken up over more than one data chunk), we are not
planning to take advantage of that, and continue to cap NBD_CMD_READ
to 32M regardless of header size.
For NBD_CMD_WRITE_ZEROES and NBD_CMD_TRIM, the block layer already
supports 64-bit operations without any effort on our part. For
NBD_CMD_BLOCK_STATUS, the client's length is a hint, and the previous
patch took care of implementing the required
NBD_REPLY_TYPE_BLOCK_STATUS_EXT.
We do not yet support clients that want to do request payload
filtering of NBD_CMD_BLOCK_STATUS; that will be added in later
patches, but is not essential for qemu as a client since qemu only
requests the single context base:allocation.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20230925192229.3186470-19-eblake@redhat.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/interop/nbd.txt | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt index f5ca25174a..9aae5e1f29 100644 --- a/docs/interop/nbd.txt +++ b/docs/interop/nbd.txt @@ -69,3 +69,4 @@ NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE NBD_CMD_FLAG_FAST_ZERO * 5.2: NBD_CMD_BLOCK_STATUS for "qemu:allocation-depth" * 7.1: NBD_FLAG_CAN_MULTI_CONN for shareable writable exports +* 8.2: NBD_OPT_EXTENDED_HEADERS |