Appendix D Quality of Service Guide
Callbacks
| ||
| 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 | |
| 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. | |
| A token grants a client some amount of | |
Tokens | ||
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 | |
| them that they will need a token to perform any | |
| first I/O after receiving the callback will then request a | |
| token from the FSM. | |
| The FSM calculates the amount of | |
| following formula: | |
| avail_nrtio = rtio_limit - rtio_current; | |
| avail_nrtio /= current_num_nonrtio_clients + 1 | |
| In the above calculation, the amount of existing | |
| has already been adjusted with the reserve parameter. As each client | |
| requests a | |
| (current_num_nonrtio_clients in the above formula) and the amount of | |
| available | |
| Each time there is a change in the amount of | |
| 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. |
StorNext 3.1.3 Installation Guide | 148 |