[TUHS] TUHS Digest, Vol 38, Issue 10

[Bakul Shah]

On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall <dave at horsfall.org> wrote:
Dave Horsfall writes:
> On Tue, 8 Jan 2019, Warner Losh wrote:
>
> >       i understood that this implemented the elevator algorithm, and
> >       possible rotational latency compensation.
> > 
> > 
> > I know what it does. I want to know why that specific name was selected.
>
> Err, because as I replied in a previous message (did you not see it?), it 
> was up to the programmer to implement an optimal strategy to access the 
> sectors, depending upon the device?  I'm not being snarky, but it seems 
> like an obvious choice (if not a hint) to me...
>
> Let's see, I need a strategy to optimise access, taking into account
> seek and rotational latency.  I know!  I'll call it XXstrategy()!

I too wondered about "strategy" in 1981 when I first worked on
unix disk drivers. My guess then was something similar.
Anything other than a FIFO strategy would improve throughput
or fairness or avoid starvation but was much more complex due
to the fact you can't reoder reads & writes.  My guess is the
original author who named it strategy had this in mind.

But these are not exactly dependent on the vagaries of
individual disk drivers.  At some point I factoroued out code
so that each specific disk driver took about 1KB of code and
shared about 7KB of common code.

> For example, I could envisage a disk where the sectors are deliberately 
> not numbered sequentially i.e. they've taken rotational latency into 
> account for you?

We did in fact use an interleave factor of more than 1 (skip
more than 1 block for consecutively numbered sectors) to
improve throughput but that had to do with slow processing.
We did discuss "dead reckoning" (invoking the service routine
right when the N+1 numbered sector was near the r/w heads) but
I don't think we implemented it.