As a final example, consider the case of a full-featured disk subsystem (Redundant Array of Very Expensive Disks, or RAVED) using a very high speed interconnect. Many clients can share these disk arrays, but it is sometimes desirable to limit a client's access to the array. QOS provides a mechanism for political bandwidth management so that no one client can consume all the bandwidth of the channel interconnects.
In such a scenario, the stripe group would always be in real-time mode. Each client would have a token specifying the number of I/Os/sec permissible. If there is need to assign different reserved bandwidth for non-real-time clients, specify the client’s bandwidth reservation in the RVIO config file.
The foundation of such an approach is a simple program that puts the stripe group into real-time mode as soon as the FSM is up and servicing requests. An example of such a program is included in the source code for the External API.
Once the stripe group is in real-time mode, the bandwidth as specified in the FSM configuration file is shared by all clients. In cases such as this, the real-time limit (rtios or rtmb) is calculated to be the total bandwidth desired to each client times the number of possible clients.
As each client attempted to access the disk subsystem, it would obtain a token. The FSM would send out callbacks adjusting down the amount of bandwidth available. No one client would be allowed to exceed the threshold specified in the non-realtime token. This assures fairness among all the clients.
