Browse Prior Art Database

Method for Reducing Path Length for Sequential I/O Processing

IP.com Disclosure Number: IPCOM000062383D
Original Publication Date: 1986-Nov-01
Included in the Prior Art Database: 2005-Mar-09
Document File: 1 page(s) / 12K

Publishing Venue

IBM

Related People

Greenberg, MS: AUTHOR [+2]

Abstract

By looking at the next element on the queue before the previous element is dequeued, the timing requirement of a disk drive is met so that revolutions of the disk are minimized for sequential I/O operations. In a UNIX* system environment, data requests occur mostly in 2K blocks. In the case of UNIX exec loading, these 2K blocks will be exactly sequential. It is required when loading data sequentially that no extra revolutions of the disk occur. This forces the disk device driver to complete an active request and start the next request within a time of 975 microseconds. Of this time, the hardware takes 465 microseconds. This allows the device driver only 510 microseconds. Additionally, new requests are given to the device driver only upon completion of the previous request.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 85% of the total text.

Page 1 of 1

Method for Reducing Path Length for Sequential I/O Processing

By looking at the next element on the queue before the previous element is dequeued, the timing requirement of a disk drive is met so that revolutions of the disk are minimized for sequential I/O operations. In a UNIX* system environment, data requests occur mostly in 2K blocks. In the case of UNIX exec loading, these 2K blocks will be exactly sequential. It is required when loading data sequentially that no extra revolutions of the disk occur. This forces the disk device driver to complete an active request and start the next request within a time of 975 microseconds. Of this time, the hardware takes 465 microseconds. This allows the device driver only 510 microseconds. Additionally, new requests are given to the device driver only upon completion of the previous request. If all of the associated path lengths were calculated, the sum would exceed the 510 microseconds by around 50%. The solution to this problem is to have the device driver look at the next element on the queue before the previous element is dequeued. If the next request is on the same cylinder, the command file is generated and issued to the drive. The dequeue activity is then done for the previous command. This has the effect of removing the system path length components from the critical path time of 510 microseconds. An additional result of this method is that for requests that are somewhat sequential, i.e., sequential within the cy...