Issue the block status command to the NBD server. If supported by the server, this causes metadata
context information about blocks beginning from the specified offset to be returned. The "count"
parameter is a hint: the server may choose to return less status, or the final block may extend beyond
the requested range. If multiple contexts are supported, the number of blocks and cumulative length of
those blocks need not be identical between contexts.
Note that not all servers can support a "count" of 4GiB or larger; nbd_get_extended_headers_negotiated(3)
indicates which servers will parse a request larger than 32 bits. The NBD protocol does not yet have a
way for a client to learn if the server will enforce an even smaller maximum block status size, although
a future extension may add a constraint visible in nbd_get_block_size(3). Furthermore, this function is
inherently limited to 32-bit values. If the server replies with a larger extent, the length of that
extent will be truncated to just below 32 bits and any further extents from the server will be ignored.
If the server replies with a status value larger than 32 bits (only possible when extended headers are in
use), the callback function will be passed an "EOVERFLOW" error. To get the full extent information from
a server that supports 64-bit extents, you must use nbd_block_status_64(3).
Depending on which metadata contexts were enabled before connecting (see nbd_add_meta_context(3)) and
which are supported by the server (see nbd_can_meta_context(3)) this call returns information about
extents by calling back to the "extent" function. The callback cannot call "nbd_*" APIs on the same
handle since it holds the handle lock and will cause a deadlock. If the callback returns -1, and no
earlier error has been detected, then the overall block status command will fail with any non-zero value
stored into the callback's "error" parameter (with a default of "EPROTO"); but any further contexts will
still invoke the callback.
The "extent" function is called once per type of metadata available, with the "user_data" passed to this
function. The "metacontext" parameter is a string such as "base:allocation". The "entries" array is an
array of pairs of integers with the first entry in each pair being the length (in bytes) of the block and
the second entry being a status/flags field which is specific to the metadata context. The number of
pairs passed to the function is "nr_entries/2". The NBD protocol document in the section about
"NBD_REPLY_TYPE_BLOCK_STATUS" describes the meaning of this array; for contexts known to libnbd,
<libnbd.h> contains constants beginning with "LIBNBD_STATE_" that may help decipher the values. On entry
to the callback, the "error" parameter contains the errno value of any previously detected error, but
even if an earlier error was detected, the current "metacontext" and "entries" are valid.
It is possible for the extent function to be called more times than you expect (if the server is buggy),
so always check the "metacontext" field to ensure you are receiving the data you expect. It is also
possible that the extent function is not called at all, even for metadata contexts that you requested.
This indicates either that the server doesn't support the context or for some other reason cannot return
the data.
The "flags" parameter may be 0 for no flags, or may contain "LIBNBD_CMD_FLAG_REQ_ONE" meaning that the
server should return only one extent per metadata context where that extent does not exceed "count"
bytes; however, libnbd does not validate that the server obeyed the flag.
By default, libnbd will reject attempts to use this function with parameters that are likely to result in
server failure, such as requesting an unknown command flag. The nbd_set_strict_mode(3) function can be
used to alter which scenarios should await a server reply rather than failing fast.
Install Now
PNG Icons
