Random Access Tape 2449

I don't agree with that definition. On average one half of a track's medium has to be traversed, and on average one-half of the tracks have to be traversed. But that means actually pbutting over much less than one half of the total medium.

A tape device is operationally equivalent to a rectangular array of cells that have to be scanned linearly: across the first row, then across the second, and so on.

A disk device is operationally equivalent to a rectangular array of cells that can be scanned by a Manhattan route. Seeking across tracks means the I-O position is (ideally) over only one cell for each pbutted track.

(In practice, of course, the medium spins under the head while the arm is seeking - see comment below - but this is irrelevant to an analysis of how much of the medium the I-O position *must* pbutt over to implement the device. A disk device *could* spin the platter only after the head has finished tracking; in practice that's infeasible, but the platter's spinning while the head is tracking is irrelevant to the device's performance in the abstract.)

Say that this hypothetical rectangular array is in fact square, of size N*N. This gives us a total tape length or disk capacity of N**2. A random seek on the tape device on average pbuttes over N**2-2 cells. On the disk device, it pbuttes over, on average, N-2 tracks at one cell per track, then N-2 cells in the destination track, for a total cost of N-2+N-2 or N.

(Obviously I'm buttuming here a single head per device and a single track tape single platter disk.)

For continuous tape, yes. Some reel-to-reel implementations don't let you rewind directly to an I-O point earlier on the medium, so you have worse average-case performance. (With probability 0.5 you have to rewind to the beginning of the tape and then seek to the new starting point.) Whether that's an appropriate consideration for this sort of estimate is an open question; obviously a lot of details are being ignored.

Not if the file system is any good. Sequential reads on *my* disk devices are contiguous far more than half the time.

The media cycling while the head is seeking track-to-track has no effect on the time for the entire I-O operation. I'm not sure what point you're making here.

I know a great many programmers who disagree with that. I had an entire course in my CS program that was devoted to data access patterns. That sort of thing is certainly less relevant to programmers working in modern general-purpose OSes now, since they're far removed from storage devices by OS caching (even, in many cases, unified hierarchical storage management), and even by the devices themselves due to caching and other optimizations (eg striping, read-ahead, etc).

However, even in these high-level environments access patterns can make a difference, and as a professional software developer I've had to analyze and tune for them.

In the real world, work needs to be done; and when I-O access patterns are suboptimal for the characteristics of the storage system (however many levels that may contain), it is sometimes necessary to look closely at how devices behave.

--

She felt increasingly (vision or nightmare?) that, though people are important, the relations between them are not, and that in particular too much fuss has been made over marriage; centuries of carnal embracement, yet man is no nearer to understanding man. -- E M Forster