Appendix D Quality of Service Guide

Callbacks

Figure 61 Callback Retraction

Example

 

In Figure 61, Client A requests some amount of RTIO as in Figure 60.

 

However, assume that Client C did not respond to the initial callback in

 

time (step 7). The FSM will return a failure to Client A for the initial RTIO

 

request, then send out callbacks to all clients indicating the stripe group is

 

no longer real-time (steps 11-14). In the example, Client C responds to the

 

second callback, so the FSM will not send out any more callbacks. The

 

stripe group is back in non-real-time mode.

 

Note that this can have interesting repercussions with file systems that

 

are soft mounted by default (such as Windows). When the caller times

 

out because other clients are not responding and then gives up and

 

returns an error to the application, if at some point the FSM is able to

 

process the RTIO request it may result in the stripe group being put into

 

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.

 

A token grants a client some amount of non-real-time I/O for a stripe

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 real-time mode, the FSM sends callbacks to all clients informing

StorNext 3.5 Installation Guide

156

Page 173
Image 173
Quantum 3.5 manual Client a requests some amount of Rtio as in Figure, Stripe group is back in non-real-time mode, Tokens