Filter
Top Products
Appendix D Quality of Service Guide
Callbacks
StorNext 3.1.3 Installation Guide 148
real-time mode after the original caller has received an error code. Both
the FSM and clients log their actions extensively to
syslog, so if this
situation arises it can be detected.
In Figure 61, if the stripe group were already in real-time mode the FSM
would only send out callbacks to those clients that already have tokens.
Once all clients responded to the token callbacks, the stripe group would
be back in its original state.
Tokens 4
A token grants a client some amount of non-real-time I/O for a stripe
group. Tokens are encapsulated in callback messages from the FSM.
Initially, no tokens are required to perform I/O. Once a stripe group is
put into real-time mode, the FSM sends callbacks to all clients informing
them that they will need a token to perform any non-real-time I/O. The
first I/O after receiving the callback will then request a non-real-time I/O
token from the FSM.
The FSM calculates the amount of non-real-time bandwidth using the
following formula:
avail_nrtio = rtio_limit - rtio_current;
avail_nrtio /= current_num_nonrtio_clients + 1
In the above calculation, the amount of existing real-time I/O (rtio_current)
has already been adjusted with the reserve parameter. As each client
requests a non-real-time I/O token, the number of clients increases
(
current_num_nonrtio_clients in the above formula) and the amount of
available non-real-time I/O decreases.
Each time there is a change in the amount of non-real-time I/O available,
the FSM sends callbacks to the clients with tokens. It is important to note
that unlike the initial set of callbacks where the FSM sent callbacks to all
connected clients, it is now only necessary to send callbacks to those
clients that have an existing token.
Once a client has a token, it can perform as much I/O per second as is
allowed by that token. It does not need to contact the FSM on every I/O
request. The FSM will inform the client whenever the token changes
value.