We next analyze the costs of EC scheduling and HR scheduling. Most of the work that is done by either is the estimation of service time for each possible candidate request; thus, we compare the number of such estimations to gain insight on the computational costs of each approach.
Assume that the size of a range is S, and the size of a track on the disk is T. Also assume that the disk supports Q outstanding requests at a given time (i.e., the queue size). We can thus derive the amount of work that needs to be performed by each approach. For simplicity, we assume each request is a write of a single block (generalizing to larger block sizes is straightforward).
For EC scheduling, assuming the full expansion, each single request in the
range-write queue expands into S requests in the expanded queue. Thus, the
amount of work, W, performed by ECS is:
 |
(1) |
In contrast, HR scheduling takes each range and divides it into a set of
requests, each of which is contained within a track. Thus, the amount of work
performed by HRS is:
 |
(2) |
However, HRS need not consider all these possibilities. Specifically, once the seek time to a track is higher than the current best seek plus rotate, HRS can stop considering whether to schedule this and other requests that are on tracks that are further away. The worst case number of tracks that must be considered is thus bounded by the number of tracks one can reach within the time of a revolution plus the time to seek to the nearest track. Thus, the equation above represents an upper bound on the amount of work HRS will do.
Even so, the equations make clear why HR scheduling performs much less work
than EC scheduling in most cases. For example, assuming that a file system
issues range writes that roughly match track size (S = T), the amount of
work performed by HRS is roughly Q. In contrast, ECS still performs 
work; as track sizes can be in the thousands, ECS will have to execute a
thousand times more work to achieve equivalent performance.