I think the original question is valid and shouldn't be dismissed, as well. During the 1980's in the peak of mainframe development, a few of us were writing channel programs, small but really cool pieces of "machine code" that would be executed on a disk controller. We did this to add a big performance gain to our software. Remember, back then memory was expensive and a resource shared by possibly hundred of concurrent jobs (programs).
With a channel program one could directly control the reading and writing of consecutive blocks, cylinders, and tracks. If you could get cylinder allocations to meet your needs, then all the read/write heads are aligned and you could write to (read from) as many platters the disk had simultaneously. If a disk had 11 platters, you would chain up the commands to point to the data and do a DMA 'blast" of data out to 11 tracks in parallel. Then, you would step out to the next consecutive track and blast another string of data, and so on.
The neat thing of channel programming is that these systems would also allow you to query the drives capabilities and you could write them dynamically. So no matter what, your software could adapt to the connected hardware. And, since the disk controllers were small computers themselves, once the channel program was set up (and they were just sets of descriptors - commands and addresses, not unlike any other machine code) the work was done asynchronously with your application code. Or you could wait if you couldn't figure out how to do that.
I think the inability to control disk I/O programatically is a serious deficiency in modern PC's, whether they are desktop or rack-mounted. Remember, the operating systems of today are not meant for people who read IBM's Principle of Operations and Supervisor Services and Macros. They are designed for the least common denominator.