I need big help with these questions:

1. Compute the seek, rotation, and transfer times for the following sets of requests: -a 0, -a 6, -a 30, -a 7,30,8, and finally -a 10,11,12,13. 2. Do the same requests above, but change the seek rate to different values: -S 2, -S 4, -S 8, -S 10, -S 40, -S 0.1. How do the times change? 3. Do the same requests above, but change the rotation rate: -R 0.1, -R 0.5, -R 0.01. How do the times change? 4. You might have noticed that some request streams would be better served with a policy better than FIFO. For example, with the request stream -a 7,30,8, what order should the requests be processed in? Now run the shortest seek-time first (SSTF) scheduler (-p SSTF) on the same workload; how long should it take (seek, rotation, transfer) for each request to be served? 5. Now do the same thing, but using the shortest access-time first (SATF) scheduler (-p SATF). Does it make any difference for the set of requests as specified by -a 7,30,8? Find a set of requests where SATF does noticeably better than SSTF; what are the conditions for a noticeable difference to arise? 6. You might have noticed that the request stream -a 10,11,12,13 wasnt particularly well handled by the disk. Why is that? Can you introduce a track skew to address this problem (-o skew, where skew is a non-negative integer)? Given the default seek rate, what should the skew be to minimize the total time for this set of requests? What about for different seek rates (e.g., -S 2, -S 4)? In general, could you write a formula to figure out the skew, given the seek rate and sector layout information? 7. Multi-zone disks pack more sectors into the outer tracks. To configure this disk in such a way, run with the -z flag. Specifically, try running some requests against a disk run with -z 10,20,30 (the numbers specify the angular space occupied by a sector, per track; in this example, the outer track will be packed with a sector every 10 degrees, the middle track every 20 degrees, and the inner track with a sector every 30 degrees). Run some random requests (e.g., -a -1 -A 5,-1,0, which specifies that random requests should be used via the -a -1 flag and that five requests ranging from 0 to the max be generated), and see if you can compute the seek, rotation, and transfer times. Use different random seeds (-s 1, -s 2, etc.). What is the bandwidth (in sectors per unit time) on the outer, middle, and inner tracks? 8. Scheduling windows determine how many sector requests a disk can examine at once in order to determine which sector to serve next. Generate some random workloads of a lot of requests (e.g., -A 1000,-1,0, with different seeds perhaps) and see how long the SATF scheduler takes when the scheduling window is changed from 1 up to the number of requests (e.g., -w 1 up to -w 1000, and some values in between). How big of scheduling window is needed to approach the best possible performance? Make a graph and see. Hint: use the -c flag and dont turn on graphics with -G to run these more quickly. When the scheduling window is set to 1, does it matter which policy you are using? 9. Avoiding starvation is important in a scheduler. Can you think of a series of requests such that a particular sector is delayed for a very long time given a policy such as SATF? Given that sequence, how does it perform if you use a bounded SATF or BSATF scheduling approach? In this approach, you specify the scheduling window (e.g., -w 4) as well as the BSATF policy (-p BSATF); the scheduler then will only move onto the next window of requests when all of the requests in the current window have been serviced. Does this solve the starvation problem? How does it perform, as compared to SATF? In general, how should a diskmake this trade-off between performance and starvation avoidance? 10. All the scheduling policies we have looked at thus far are greedy, in that they simply pick the next best option instead of looking for the optimal schedule over a set of requests. Can you find a set of requests in which this greedy approach is not optimal?