Issue a read command to the NBD server for the range starting at "offset" and ending at "offset" +
"count" - 1. The server's response may be subdivided into chunks which may arrive out of order before
reassembly into the original buffer; the "chunk" callback is used for notification after each chunk
arrives, and may perform additional sanity checking on the server's reply. 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 read command will fail with
any non-zero value stored into the callback's "error" parameter (with a default of "EPROTO"); but any
further chunks will still invoke the callback.
The "chunk" function is called once per chunk of data received, with the "user_data" passed to this
function. The "subbuf" and "count" parameters represent the subset of the original buffer which has just
been populated by results from the server (in C, "subbuf" always points within the original "buf"; but
this guarantee may not extend to other language bindings). The "offset" parameter represents the absolute
offset at which "subbuf" begins within the image (note that this is not the relative offset of "subbuf"
within the original buffer "buf"). Changes to "error" on output are ignored unless the callback fails.
The input meaning of the "error" parameter is controlled by the "status" parameter, which is one of
"LIBNBD_READ_DATA" = 1
"subbuf" was populated with "count" bytes of data. On input, "error" contains the errno value of any
earlier detected error, or zero.
"LIBNBD_READ_HOLE" = 2
"subbuf" represents a hole, and contains "count" NUL bytes. On input, "error" contains the errno
value of any earlier detected error, or zero.
"LIBNBD_READ_ERROR" = 3
"count" is 0, so "subbuf" is unusable. On input, "error" contains the errno value reported by the
server as occurring while reading that "offset", regardless if any earlier error has been detected.
Future NBD extensions may permit other values for "status", but those will not be returned to a client
that has not opted in to requesting such extensions. If the server is non-compliant, it is possible for
the "chunk" function to be called more times than you expect or with "count" 0 for "LIBNBD_READ_DATA" or
"LIBNBD_READ_HOLE". It is also possible that the "chunk" function is not called at all (in particular,
"LIBNBD_READ_ERROR" is used only when an error is associated with a particular offset, and not when the
server reports a generic error), but you are guaranteed that the callback was called at least once if the
overall read succeeds. Libnbd does not validate that the server obeyed the requirement that a read call
must not have overlapping chunks and must not succeed without enough chunks to cover the entire request.
Note that libnbd currently enforces a maximum read buffer of 64MiB, even if the server would permit a
larger buffer in a single transaction; attempts to exceed this will result in an "ERANGE" error. The
server may enforce a smaller limit, which can be learned with nbd_get_block_size(3).
The "flags" parameter may be 0 for no flags, or may contain "LIBNBD_CMD_FLAG_DF" meaning that the server
should not reply with more than one fragment (if that is supported - some servers cannot do this, see
nbd_can_df(3)). Libnbd does not validate that the server actually obeys the flag.
Note that if this command fails, and nbd_get_pread_initialize(3) returns true, then libnbd sanitized
"buf", but it is unspecified whether the contents of "buf" will read as zero or as partial results from
the server. If nbd_get_pread_initialize(3) returns false, then libnbd did not sanitize "buf", and the
contents are undefined on failure.
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
