Your colleague's idea works well on the front-end but falls down badly on the back end. Breaking a sector into pieces and distributing them around the track does indeed reduce the worst-case possible rotational latency when starting the sector read. However, it also guarantees the rotational delay required to read the whole sector will be one disk rotation, which is far more than the rotational delay of the original scheme, which was proportional to the size of the sector relative to the size of the track.
In addition, the drive electronics required to read a fragmented sector in arbitrary cyclic order is much more complicated than the electronics required in the original scheme.
A device driver provides a way to share a device that would normally require exclusive access. A resource that can be shared among any number of requesters cannot be a contributor to a deadlock condition.
For example, giving processes direct access to the disk would result in chaos as each process steps all over the commands issued by the previous processes. A disk driver lets each process drop off disk-io requests and synchronizes the processes with their requests' eventual execution.
Many: the disparity of transfer rates between a tape drive and a process is so great that much buffer space will be needed to allow some degree of useful overlap between computation and I-O. This means that a high-performance driver for a tape drive needs to provide enormous buffer space.
Few: the disparity of transfer rates is great, but so is the amount of data held by a tape drive, and it would wildly inefficient to pre-allocate enough buffer space to cover the disparity, and naive to assume that much space could be allocated dynamically. It would be better to provide some kind of asynchronous interface to the tape drive to give tape-drive users the ability to implement their own overlapping buffering schemes as they see fit.
The system must grant the allocation in a single block; incremental grants raise the risk of deadlock because they re-introduce incremental allocations with holding.
For example, suppose processes P1 and P2 both request two tape drives up front, and let the system have a total of two tape drives. With block grants, one process gets both tape drives and the other waits. With incremental grants, each process could end up with one tape drive (due to an unfortunate scheduler intervention, for example) and then block waiting for the other tape drive, at which point deadlock settles in.
On the other hand, it would also be correct to note that the Banker's Algorithm requires up-front allocation (in the form of a maximum resource requirement) and manages incremental grants in such a way as to avoid deadlock.
This page last modified on 5 November 2001.