Today we continue our discussion of the  paper titled "Pelican: a  building block for exascale cold data storage". Pelican treats a group of disks as a single schedulable unit. Resource restrictions such as power consumption, vibrations and failure domains are expressed as constraints over these units.

With the help of resource constraints and scheduling units, Pelican aims to be better than its over provisioned counterpart racks using computations in software stacks

Pelican uses resources from a set of resource domains which is a subset of disks. Pelican proposes a data layout and IO scheduling algorithms by expressing these resource domains as constraints over the disks. We were discussing evaluation of Pelican.

Pelican was measured under different load regimes. The disk throughput was measured using a quiescent system. Seeks are simulated by including a constant latency of 4.2 ms for all disk accesses and it was found that seek latency has negligible impact on performance. It was also found that the latency of spinning the disk up and mounting the volume heavily dominate over seek time. The distribution for mount delays was widely affected by the load on the system. 
Pelican was compared with a system denoted by FP that was subject to no resource constraints. The disks were never spun down but the same topology was used.  Pelican partitions the disks into 48 groups whereas in FP all 48 groups could be concurrently accessed. Reads are done at full throughput because the stripe stacks are contiguous on disk.
Pelican supports a wide variety of workloads. A full range of workloads is covered by parameters representing characteristics and using a Poisson process with an average arrival rate of 1 / lambda. The Poisson process allows us to model random events along a real line using a single parameter which in this case is made to vary with lambda from 0.125 to 16. The average request rate per second is shown  rather than the lambda value because this makes the results clear. The workloads are all such that Pelican can focus on servicing read requests which are randomly distributed across all the blobs stored in the rack.

#codingexercise

Check if a given array is a pre-order traversal of a binary search tree

bool IsPre(List<int>nums)

{

var stk = new Stack<int>();

int root = INT_MIN;

for (int i = 0; i < nums.Count; i++)

{

    if (nums[i]  < root)

         return false;

   while (!stk.empty() && s.top() < nums[i])

   {

         root = stk.top()

         stk.pop();

   }

   stk.push(nums[i]);

}

return true;

}

50 30 35 70 80
35 30 80 70 50
The same linear scan above can be applied to finding the next greater element for every element in an array.
void GetNextGreater(List<int> arr)
{
if (arr.count == 0) return;
int element, next;
var stk = new Stack();
stk.push(arr[0]);
for (int I = 1; I < arr.Count; i++)
{
next = arr[I];
If (isEmpty(stk) == false)
{
element = stk.pop();
while (element < next)
{
Console.Write("{0} next {1}", element, next);
if (isEmpty(stk) == true) break;
element = stk.pop()
}
if (element > next)
    stk.push(element)
}
stk.push(next)
}
while (stk.empty() == false)
{
element = stk.pop()
next = -1;
Console.Write("{0} next {1}", element, next);
}
}

The same scan that holds true for preorder check does not hold true for post order because the root is no longer the first encountered that will be greater than both the left and right in a BST.
So the solution would be to reverse scan the array

bool IsPost(List<int>nums)

{

var stk = new Stack<int>();

int root = INT_MIN;

for (int i = nums.Count - 1; i> 0; i--)

{

   while (!stk.empty() && s.top() > nums[i])

   {

         root = stk.top()

         stk.pop();

   }

    if (nums[i]  < root)

         return false;

   stk.push(nums[i]);

}

return true;

}

50 30 35 70 80
35 30 80 70 50