Displaying 3 results from an estimated 3 matches for "e7b1948d51".
2022 Dec 16
1
[PATCH v2 1/6] spec: Recommend cap on NBD_REPLY_TYPE_BLOCK_STATUS length
...r to
> just document this as a restriction on viable server implementations
> than to add yet another round of handshaking. Also, mentioning
> amplification effects is worthwhile.
>
> When qemu first implemented NBD_CMD_BLOCK_STATUS for the
> base:allocation context (qemu commit e7b1948d51, Mar 2018), it behaved
> as if NBD_CMD_FLAG_REQ_ONE were always passed by the client, and never
> responded with more than one extent. Later, when adding its
> qemu:dirty-bitmap:XYZ context extension (qemu commit 3d068aff16, Jun
> 2018), it added a cap to 128k extents (1M+4 bytes), and...
2023 Mar 03
1
[PATCH v2 1/6] spec: Recommend cap on NBD_REPLY_TYPE_BLOCK_STATUS length
...his as a restriction on viable server implementations
> > than to add yet another round of handshaking. Also, mentioning
> > amplification effects is worthwhile.
> >
> > When qemu first implemented NBD_CMD_BLOCK_STATUS for the
> > base:allocation context (qemu commit e7b1948d51, Mar 2018), it behaved
> > as if NBD_CMD_FLAG_REQ_ONE were always passed by the client, and never
> > responded with more than one extent. Later, when adding its
> > qemu:dirty-bitmap:XYZ context extension (qemu commit 3d068aff16, Jun
> > 2018), it added a cap to 128k exten...
2023 Apr 13
6
[PATCH v3 0/6] NBD 64-bit extensions (spec only)
v2 was here:
https://lists.debian.org/nbd/2022/11/msg00030.html
The bulk of the changes since then are:
- forbid NBD_OPT_EXPORT_NAME once extended headers are negotiated (Wouter)
- consistently use 'maximum payload', rather than a haphazard mix of
'maximum block payload' (Vladimir)
At this point, I want to make sure we are happy with the spec before
re-posting patches for