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

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

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

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.