Policy Framework

Policies and mechanisms for the migrations of the stripes are separated, with various mechanisms for migrations provided by the low level TSS driver in the kernel. The policies are imposed over the TSS device, by separate user level programs, that run as daemons, with suitable permissions. These policy routines communicate with the low level mechanisms through the ioctl() calls.

The low level TSS device does take some policy decisions in extreme situations such as when there is no free stripe for a particular I/O operation. These policy decisions at the kernel level cannot be avoided, as there may be no policy running at the user level forcing the kernel to take the decisions.

The TSS device driver maintains temperature and access fields for each stripe. Temperature field accumulates the accesses over a period of time. Access field indicates whether the stripe has been accessed in the recent past. The aging is the process of increasing the temperature of all recently accessed stripes, depending on its access field. Uptodate field also indicates whether the stripe has been accessed in recent past and is used by degrade process which reduces the stripe temperature using exponential degradation. We need separate access and uptodate field, as the aging and degradation can happen at different frequencies. Temperature of a stripe is reset during the migration of that stripe.

Following are the different mechanisms provided by the TSS driver that can be used by policy routines.

• Get/Set the temperature of a particular stripe
• Reset temperatures of all the stripes
• Do an aging on the stripes
• Do a temperature degradation on the stripes
• Get the number of stripes of each kind of personality
• Get the maximum temperature of any kind of personality
• Victimize / promote a particular stripe, from a particular RAID level.
• Victimize / promote the best possible stripe, from a particular RAID level.

It is important to note that the information provided by the kernel about the stripes in the above mechanisms are as of that particular instant and may not be true at a later point in time when the user level application may use the information. There is no lock held in the kernel across requests. This approach was chosen as the policy enforcement is more to optimize the performance and not a strict guideline.

The advantages of having the policies separate from the low level device driver are the following:

• Different policies can be implemented depending on the kind of application and the hardware.
• None, one or more policies can be running at the same time.

Following are the policies that were implemented on the TSS device:

1. Watermark Policy - In this policy, there are lower and upper watermarks fixed on the three kinds of stripe personalities. Periodic checks are done to check whether the number of stripes of all the personalities conform to the corresponding watermarks. If not, migrations of the stripes are performed, so as to conform to the watermarks.

   This policy is simple to implement but has the disadvantage of being static. It does the migrations of the stripes based on temperature.

2. Five Minute Rule - The Five Minute Rule is a way of organizing hierarchical memory, using the performance and the cost considerations, as proposed in [8]. The idea originally proposed for organizing memory hierarchy can be modified and applied to the TSS device as well. Adapting the original formula[8],

   
   

   $$\frac{(\frac{Cache\_Cost}{Byte}-\frac{Mem\_Cost}{Byte})*\nonumber \\ Obj\_Bytes}{Obj\_Access\_Per\_Sec\_Cost}$$
   
   
   that gives the time interval in memory before demotion to disk if there are no accesses in that interval, for the hierarchical TSS device, we get the time interval for RAID levels A and B as

   
   

   $$\frac{(\frac{RAIDA\_Cost}{byte} - \frac{RAIDB\_Cost}{byte}) * Obj\_Bytes} {(RAIDA\_acc/s\_cost - RAIDB\_acc/s\_cost)}$$
   
   
   The acc/s_cost for individual RAID devices can be got from the simulations and used here. The frequency values determined as above can be used by the policy routine managing the device and can trigger migrations depending on these frequencies.