Disk I-O package

The ECS system disk I-O package was divided into the usual two pieces, one consisting of PPU code and the other in central memory. It provided the ability to read or write records starting at any sector boundary and of lengths 64, 129, 257, or 513 60-bit words. Automatically included in each record, invisible to the user, was the disk address of the start of the record. This acted as a check on the disk positioning mechanism. Also provided were buffers of these same sizes in an ECS file. Event channels were provided to hold lists of available buffers. Up to 512 requests could be pending at one time. These were sorted by disk arm position and starting sector. The arm was moved elevator fashion back and forth, and upon reaching a disk position with pending requests, all such requests, pending at the time the position was reached, were serviced. The arm was then moved to the next position with outstanding requests. Within a given position requests were selected approximately in the order of disk rotation. The algorithm used was to select a request at some distance beyond the current rotational position, prepare for the transfer, check that the I-O request could still be made without an intervening full rotation, then execute that actual I-O instruction. The only suitable final check was to insist that the rotational position be more than one sector in advance of the desired sector. For reads, this led to choosing a request about 3 sectors beyond the current disk position. Write requests required more preparation time than reads as it was necessary to move the data from ECS to the PPU before the write could proceed. This move required as much time as needed to write the data on the disk. I-O requests with the same arm position and starting sector were handled in the order made. This was the only order condition satisfied by the algorithm. Sixty-four words was the maximum size record that could be written in one sector position, allowing for two internal address check bytes. The 129 and 257 word records fit in 2 and 4 sectors respectively, while the 513 word records fit in 7 sectors. Except for the 64 word records, the others were a power of 2 plus one, allowing one check word to be used by the next level of the system, and still provide power of two record sizes to the ultimate user. To make a read request, the higher level disk system would first obtain a slot from a slot event channel for permission to make the request. The disk system would then send an event, on a request event channel, which would contain the disk address for the request, the size of the request, an internal number to identify the response and the index of the slot for the request obtained from the slot event channel. The request would be stored by the ECS I-O system code in an internal table indexed by slot number. These entries were chained together for equal arm positions and eventually for equal starting sector. The response would appear on a response event channel, and would contain the internal number of the request, the index of a buffer containing the data and a completion code which indicated if any errors had occurred. The higher level disk system would eventually release the buffer by sending an event containing the index of the buffer on a buffer event channel. To make a write request the higher level disk system would first obtain the index of a buffer from a buffer event channel, and would write the data in that buffer. Then, as in the case of a read request, it would obtain a slot number and send the request containing the buffer index, slot index, internal number, disk address and size of the request. The response event would contain a completion code, and in the event that there were no errors the buffer would have been automatically released. (Figure 3 diagrams the flow of events between the higher level disk system and the ECS system disk driver described here.) Information as to the current position of the disk arm and current direction of motion was made available to the higher level disk system so that most writes could be in a position expected to be serviced soon. This, together with the fact that a read buffer was not assigned until the actual read was about to start, reduced the amount of ECS space required for buffers. It was expected that under heavy load a complete scan of the disk might take several seconds, possibly up to 10. However, any given block of data would be held in buffers for only a fraction of this time.

 

Figure 3: Sketch of event flow between disk system code and ECS system disk driver. The request and response channels carry a 60 bit coded request or response. The other channels carry indices of available items.

9#9