Re: [Libguestfs] [libnbd PATCH v3 08/22] block_status: Track 64-bit extents internally

[Eric Blake]

[fixing some of my editing errors]

On Fri, Jun 09, 2023 at 10:42:25AM -0500, Eric Blake wrote:
[...]
> 
> The tl;dr summary of the above discourse:
> There are two orthogonal communications going on:
> 
> libnbd <-> server  choice of NBD_REPLY_TYPE_BLOCK_STATUS{,_EXT}
> app <-> libnbd     choice of nbd_block_status() or nbd_block_status_64()
> 
> and all four combinations are easy to encounter when loading the .so
> for libnbd 1.18:
> 
> 32 x 32 (app compiled against libnbd 1.16 to server A)
> 64 x 32 (app compiled against libnbd 1.16 to server B)
> 32 x 64 (app compiled against libnbd 1.18 to server A)
> 64 x 64 (app compiled against libnbd 1.18 to server B)
> 
> and we want all four combinations to work insofar as possible.  32x32
> and 64x64 obviously work, as does 32x64 (widening the server's
> responses never fails); for 32x64 (using the 32-bit nbd_block_status()
> API to access a server's response through 64-bit
> NBD_REPLY_TYPE_BLOCK_STATUS), accessing a metacontext with large flags

for 64x32 (using the 32-bit nbd_block_status() to access a server's
response through 64-bit NBD_REPLY_TYPE_BLOCK_STATUS_EXT),

> changes from fail early to fail late; and accessing a metacontext with
> 32-bit flags but now potential 64-bit lengths obeys overall NBD
> semantics that a block status response can be truncated as long as it
> makes progress (the app shouldn't care whether it was the server or
> libnbd that did the truncation).
>
[...]
> 
> It is indeed a bug if a server replies with
> NBD_REPLY_TYPE_BLOCK_STATUS_EXT for a client that did not request
> extended headers.  But it is also a bug if a server replise with

replies

> NBD_REPLY_TYPE_BLOCK_STATUS for a client that did request extended
> headers, even if the reply does not need more than 32 bits for either
> the length or the flags.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org