Quality of Service Evaluation

Before we consider how to enhance the inode and datablock allocators to utilise the QoS metadata, we introduce a means to evaluate a given data layout with respect to the desired and delivered QoS attributes. The fun-damental idea is to calculate the difference (∆) between the scores of QoS delivered (QoSdlv) and desired (QoSdes), as exemplified in Equation 4.1.

∆ = QoSdlv− QoSdes (4.1) When the value of ∆ is zero, it indicates a perfect match is in place between desired and delivered QoS for a particular attribute. This means that the closer the value is to zero, the better the data layout. When the calculated value of ∆ is negative, there is underprovisioning taking place, since the QoS score desired is higher than delivered. A positive value means the data lies in a storage area that is capable of delivering a higher level of QoS; therefore overprovisioning is taking place.

In order to evaluate the layout for all the QoS attributes that are in use in a given system, an aggregate function is needed. Considering a set of attributes attr, Equation 4.2 presents our initial concept to realise this aggregation in the form of a sum, adding up every ∆a calculated for each attribute a. Similarly to Equation 4.1, every ∆a is calculated through the difference between the scores of QoS delivered (now QoSdlv^a , as it is specific to attribute a) and desired (QoSdes^a ).

P

a∈{attr}∆a, where

∆^a= QoSdlv^a − QoSdes^a

(4.2) In practice, calculating ∆a involves traversing the inode’s i block array (explained in Section 3.4 and illustrated in Figure 3.8). Because datablocks for a particular inode can be allocated on any block group in the entire filesystem, it is necessary to use QoSdes^a for every datablock of the inode un-der evaluation, while using QoSdlv^a for the block group where each datablock resides.

To illustrate this scenario, Figure 4.2 presents two block groups b1 and b2 that deliver QoS attributes a1 and a2 with different scores. An inode, allocated in the inode table of block group b1 and requiring these attributes with scores a1 = 75 and a2 = 60, has three datablocks allocated in b1 and another three in b2. The score for this example is obtained by summing the differences of QoSdlv and QoSdes for each datablock, considering the block group where it resides. Table 4.4 shows how the calculation is done.

The scenario proposed does not contain block groups capable of delivering exactly the same score required by the inode. Despite that fact and accord-ing to the steps illustrated in the table, the resultaccord-ing score for this data

1−indirect addressing

Figure 4.2.: Example, for QoS evaluation, of an inode with datablocks allo-cated in two different block groups.

P

(3 × (100 − 75))

Three datablocks requiring score 75 for attribute a1, re-siding in block group b1 that delivers score 100 for the same attribute.

(3 × (50 − 75))

Three datablocks requiring score 75 for attribute a1, re-siding in block group b2 that delivers score 50 for the same attribute.

(3 × (70 − 60))

Three datablocks requiring score 60 for attribute a2, re-siding in block group b1 that delivers score 70 for the same attribute.

(3 × (50 − 60))

Three datablocks requiring score 60 for attribute a2, re-siding in block group b2 that delivers score 50 for the same attribute.

=

The resulting score is zero, although there is both over-and underprovisioning happening, suggesting that a per-fect layout is in order.

Table 4.4.: Step-by-step QoS evaluation of an example containing dat-ablocks scattered over two different block groups.

layout is zero. This suggests that a perfect layout is in place, with respect to QoS evaluation, even though data allocated in b1 is overprovisioned and data allocated in b2 is underprovisioned.

This problem raised the question of evaluating under- and overprovision-ing cases with a different method. In order to achieve this, the QoS evalua-tion formula was modified to include a provisioning factor p. Equaevalua-tion 4.3 presents this enhancement.

Using the new evaluation formula, the sum will always be composed of positive numbers, since p will switch the sign of ∆a if it is negative. To differentiate the provisioning scheme the formula offers cu and co, which are constant factors applied to indicate how worst it is to under- or overprovi-sion. For example, if one system considers underprovisioning twice as bad as overprovisioning, c^u and c^o may be set to 2 and 1 respectively, adding twice the score every time ∆^a is less than zero.

Re-evaluating the previous example with the new formula and the pro-posed values for c^u and c^o, it is possible to observe how the final score is affected by data that is not perfectly matched. Along with these new re-sults, we also present cases where all datablocks are either in block group b1 or b2. The results are expressed in Table 4.5.

Evaluated

Scenario Description Score

315 Same scenario as before, having three datablocks allocated in block group b1 and three datablocks allocated in block group b2.

420 Scenario with most underprovisioning, where all six datablocks have been allocated to block group b2.

210 Scenario with most overprovisioning, where all six datablocks have been allocated to block group b1.

Table 4.5.: Data layout evaluation of three different scenarios using the pro-visioning factor.

Comparing the results of the original evaluation scheme with the new one that takes provisioning into account, it is possible to observe how the

scores are more informative. Firstly, none of the results indicate perfect allocation, considering there are no block groups capable of delivering ex-actly what is desired. Secondly, the new results show that if some or all data is underprovisioned, the resulting scores are higher than if all data is overprovisioned.

Finally, when applying the score evaluation formula to calculate possible layouts with the intent to allocate data, we considered situations where ties could happen between different attributes. For example, if a scenario presents a situation where it is impossible to meet both a performance and a reliability requirement, possibly because the infrastructure is unable to deliver high values for both attributes simultaneously, breaking the tie may be required. In order to achieve this, one last multiplier factor mais added to the formula, as shown in Equation 4.4.

P

a∈{attr}∆^a× p × m^a, where

∆a= QoSdlv^a − QoSdes^a , p =

( −|c^u| if ∆^a< 0

|co| if ∆a≥ 0 , and m^a= attribute multiplier