Homework 5 Solutions

22C:116, Fall 2000

Douglas W. Jones

  1. Part a: What is the maximum, minimum and expected rotational latency for this disk.
    20 revolutions per second implies 0.05 seconds per revolution. The expected rotational latency is 1/2 of one revolution, or 0.025 seconds.

    Part b: What is the maximum, minimum and expected head positioning latency for this disk. Assume that the initial and final cylinders are selected uniformly from among the available cylinders.

    Given d=1/2at2, where d=200 and t=0.1, we can solve and get a=40000 tracks per second squared. Therefore, d=20000t2 is the formula for track to track moves on this disk, or t=sqrt(d/20000). The probability distribution for the expected length of a cylinder to cylinder move is a triangular distribution with a peak at 0 and going to zero at -200 and 200 (this assumes that starting and ending track addresses are selected with a uniform distribution). Integrating t*p(t) (time for move times probability of that time) over this distribution, we get 0.053 sec for the expected seek time.

    The naieve solution, that the average move is 100 cylinders, so we simply substitute this average move into the formula for the time per move, gives us 0.071 seconds for the expected seek time. The error of 0.018 seconds gives a hint of the value of proper use of probability. For most purposes, a 10% error is acceptable, but here, the naive answer is off by 34%).

    Part c: What is the time taken to read or write one sector?

    There are 24 sectors per track, and 0.05 seconds per revolution. This means that we have 0.05/24 or 0.002 seconds per sector. Since no information was given about the length of the intersector gap, this is the best we can do.

    Part d: What is the expected time per I/O operation, assuming uniform random sequences of disk addresses.

    Rotational plus seek plus transfer time is 0.025+0.053+0.002 or 0.080 sec.

    Part d: What is the storage capacity of this disk?

    Surfaces times cylinders times sectors per track times bytes per sector, is 20x200x24x512 or 49,152,000 bytes.

  2. The Problem: Taking into account everything you know about the UNIX file system, describe all disk I/O that would result from:
    lseek(X,10000,0);
    write(X,B,1);
    First, we know that the file is already open, which means that these lines of code will not search any directory, and the I-node is already in main memory. Given a sector size of 512 bytes, this is a reference to byte 272 of sector 19 of the file. The disk address of sector 19 is not directly included in the I-node (only the first 10 are), but rather, it is included in the first index sector referenced by the I-node (the index sector for single-indirect reference). Therefore:

    Disk access 1 - read the first index sector referenced by the I-node.

    Now, we can translate the address of sector 19 to a physical disk address. The write operation is not a full sector, nor is it sector aligned. Therefore, to change byte 272 of the sector, we must first read the sector.

    Disk access 2 - read sector 19 of the file into a buffer in main memory.

    The write operation can now complete, changing byte 272 of the sector in the buffer. We are done! The buffer will be written back to disk later, when the file is closed, when a new seek is done, or when reading or writing advances into another sector.

  3. A Problem Why is it that the disk drivers included with personal computer operating systems rarely contain sophisticated disk schedulers, while the disk drivers included with timesharing systems and network servers frequently do contain good disk schedulers.
    On a personal computer, there is rarely more than one ready process, and that process is usually unable to post more than one disk I/O request at a time. As a result, there is rarely more than one pending disk request, so all scheduling policies are equivalent. On a server or timesharing system, there are multiple processes operating on behalf of different users or remote clients, and as a result, the number of pending disk requests can be large enough to make scheduling useful.