1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
=head1 NAME
nbd_block_status_64 - send block status command, with 64-bit callback
=head1 SYNOPSIS
#include <libnbd.h>
typedef struct {
int (*callback) (void *user_data,
const char *metacontext,
uint64_t offset, nbd_extent *entries,
size_t nr_entries, int *error);
void *user_data;
void (*free) (void *user_data);
} nbd_extent64_callback;
int nbd_block_status_64 (
struct nbd_handle *h, uint64_t count,
uint64_t offset,
nbd_extent64_callback extent64_callback,
uint32_t flags
);
=head1 DESCRIPTION
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 C<count> parameter is a hint: the
server may choose to return less status, or the final block
may extend beyond the requested range. When multiple contexts
are supported, the number of blocks and cumulative length
of those blocks need not be identical between contexts; this
command generally returns the status of all negotiated contexts,
while some servers also support a filtered request (see
L<nbd_can_block_status_payload(3)>, L<nbd_block_status_filter(3)>).
Note that not all servers can support a C<count> of 4GiB or larger;
L<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
L<nbd_get_block_size(3)>.
Depending on which metadata contexts were enabled before
connecting (see L<nbd_add_meta_context(3)>) and which are
supported by the server (see L<nbd_can_meta_context(3)>) this call
returns information about extents by calling back to the
C<extent64> function. The callback cannot call C<nbd_*> APIs on the
same handle since it holds the handle lock and will
cause a deadlock. If the callback returns C<-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
C<error> parameter (with a default of C<EPROTO>); but any further
contexts will still invoke the callback.
The C<extent64> function is called once per type of metadata available,
with the C<user_data> passed to this function. The C<metacontext>
parameter is a string such as C<"base:allocation">. The C<entries>
array is an array of B<nbd_extent> structs, containing length (in bytes)
of the block and a status/flags field which is specific to the metadata
context. The number of array entries passed to the function is
C<nr_entries>. The NBD protocol document in the section about
C<NBD_REPLY_TYPE_BLOCK_STATUS> describes the meaning of this array;
for contexts known to libnbd, B<E<lt>libnbd.hE<gt>> contains constants
beginning with C<LIBNBD_STATE_> that may help decipher the values.
On entry to the callback, the C<error> parameter contains the errno
value of any previously detected error.
It is possible for the extent function to be called
more times than you expect (if the server is buggy),
so always check the C<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 C<flags> parameter may be C<0> for no flags, or may contain
C<LIBNBD_CMD_FLAG_REQ_ONE> meaning that the server should
return only one extent per metadata context where that extent
does not exceed C<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 L<nbd_set_strict_mode(3)>
function can be used to alter which scenarios should await a server
reply rather than failing fast.
=head1 RETURN VALUE
If the call is successful the function returns C<0>.
=head1 ERRORS
On error C<-1> is returned.
Refer to L<libnbd(3)/ERROR HANDLING>
for how to get further details of the error.
The following parameters must not be NULL: C<h>.
For more information see L<libnbd(3)/Non-NULL parameters>.
=head1 HANDLE STATE
nbd_block_status_64
can be called when the handle is in the following state:
┌─────────────────────────────────────┬─────────────────────────┐
│ Handle created, before connecting │ ❌ error │
│ Connecting │ ❌ error │
│ Connecting & handshaking (opt_mode) │ ❌ error │
│ Connected to the server │ ✅ allowed │
│ Connection shut down │ ❌ error │
│ Handle dead │ ❌ error │
└─────────────────────────────────────┴─────────────────────────┘
=head1 VERSION
This function first appeared in libnbd 1.18.
If you need to test if this function is available at compile time
check if the following macro is defined:
#define LIBNBD_HAVE_NBD_BLOCK_STATUS_64 1
=head1 SEE ALSO
L<nbd_add_meta_context(3)>,
L<nbd_aio_block_status_64(3)>,
L<nbd_block_status(3)>,
L<nbd_block_status_filter(3)>,
L<nbd_can_block_status_payload(3)>,
L<nbd_can_meta_context(3)>,
L<nbd_create(3)>,
L<nbd_get_block_size(3)>,
L<nbd_get_extended_headers_negotiated(3)>,
L<nbd_set_strict_mode(3)>,
L<libnbd(3)>.
=head1 AUTHORS
Eric Blake
Richard W.M. Jones
=head1 COPYRIGHT
Copyright Red Hat
|
