[TUHS] Origin of the name 'strategy'

[TUHS] Origin of the name 'strategy'

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

So what's the origin of the name 'strategy'  for the I/O routine in Unix
that drivers provide? Everything I've found in the early papers just says
that's what the routine is called. Is there a story behind why it was
chosen? My own theory is that it's in the sense of 'coping strategy' when
the driver needs to service more I/O for the upper layers, but that's just
a WAG.

Warner

[-- Attachment #2: Type: text/html, Size: 479 bytes --]

Re: [TUHS] Origin of the name 'strategy'

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Mon, 7 Jan 2019, Warner Losh wrote:

> So what's the origin of the name 'strategy'  for the I/O routine in Unix 
> that drivers provide? Everything I've found in the early papers just 
> says that's what the routine is called. Is there a story behind why it 
> was chosen? My own theory is that it's in the sense of 'coping strategy' 
> when the driver needs to service more I/O for the upper layers, but 
> that's just a WAG.

My guess is that it's supposed to optimise disk access; Ken may know.

-- Dave

Re: [TUHS] Origin of the name 'strategy'

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Mon, Jan 7, 2019 at 4:22 PM Warner Losh <imp@bsdimp.com> wrote:

> So what's the origin of the name 'strategy'  for the I/O routine in Unix
> that drivers provide? Everything I've found in the early papers just says
> that's what the routine is called. Is there a story behind why it was
> chosen? My own theory is that it's in the sense of 'coping strategy' when
> the driver needs to service more I/O for the upper layers, but that's just
> a WAG.
>

I always thought it had to do with computing the optimal strategy for
writing blocks to the disc device....  I wonder where I got that impression
from.  Perhaps reading Bach?

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1033 bytes --]

Re: [TUHS] Origin of the name 'strategy'

[Erik E. Fair]

>From: Dan Cross <crossd@gmail.com>
>Date: Mon, 7 Jan 2019 16:28:42 -0500
>
>I always thought it had to do with computing the optimal strategy for
>writing blocks to the disc device....  I wonder where I got that impression
>from.  Perhaps reading Bach?

Perhaps from reading the strategy routines of disk device drivers? That's where disksort() routine to perform HDA seek minimization via elevator sort is called. Still true in NetBSD today, though some of the routine names have changed. That would seem worth of being called a "strategy".

	Erik Fair

Re: [TUHS] Origin of the name 'strategy'

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 5135 bytes --]

below....

On Mon, Jan 7, 2019 at 4:22 PM Warner Losh <imp@bsdimp.com> wrote:

> So what's the origin of the name 'strategy'  for the I/O routine in Unix
> that drivers provide? Everything I've found in the early papers just says
> that's what the routine is called. Is there a story behind why it was
> chosen? My own theory is that it's in the sense of 'coping strategy' when
> the driver needs to service more I/O for the upper layers, but that's just
> a WAG.
>

FWIW:   Warren has a scan of the 1976 USG document:   "UNIX Program
Description"  Program Generic PG-1C300 Issue 2
From the section called:  BIO01 - Block I/O, on the 5th page I think  there
seems to be a hint of why it was called strategy.   Under the description
of the breada routine are the words:

*Read ahead is a technique whereby an attempt is made to anticipate where
the next read request on a device will be and to preread that data. In this
manner, the program requesting the read will not be subjected to positional
and rotational latency or device queuing, if read ahead is completed before
the next block is requested. There are different strategies that can be
used for-doing read ahead. On UNIX, all reads (not including physical I/O)
result in a full 512 byte block being read from· the device. Smaller
amounts of data could be read if a program requested it, however, since
disks transfer times are small in comparison to positional and rotational
latency times, any extra transfer is inconsequential. Also, most DEC disks
are designed around a 512 byte sector and while fewer than 512 bytes may be
specified, the disk controller is busy until a full sector has been
transferred. By reading the full 512 bytes, any subsequent read or write
which references data within that block will not have to be lead (if the
block does not leave the system). Besides the advantage gained by reading a
minimum of 512 bytes instead of the desired quantities, the next block is
anticipated and read under certain conditions. Thus, one request will spawn
several read requests to bring data into the system. A routine for finding
a block that is already in memory (bio.c/incore) must be available to
determine whether any reads need be done and the read ahead strategy must
be capable of determining when read ahead should be discontinued so that
superfluous reads are not generated.*

*The strategy adopted under UNIX is to pursue read ahead as long as a
process is reading (512 byte blocks) sequentially through a file or a
device. When the first non sequential read is requested, read ahead is
discontinued and is not restarted until sequential accesses begin again. *

*Bio.c/breada carries out the read ahead operation. Starting and stopping
read ahead and determining which block number in a file or on a device is
the read ahead block ("rablkno") is done by the higher level function
rdwri.c/readi. *

*In implementing the read ahead strategy, bio.c/breada makes use of
bio.c/incore to determine whether a block is already in memory. For the
desired block "blkno", the bio.c/breada function behaves exactly like
bio.c/bread. That is, a synchronous read is performed and the process
requesting the read is roadblocked until it is completed. Since the desired
block may already be within system. bio.c/incore is called to look for that
block among the buffers on the freelist (bfreelist"). If the block is
already in memory. bio.c/bread is called to get the buffer. If the desired
biock has not already been read by a previous read operation then
bio.c/getblk is called to see if the block is possibly on a device queue
waiting for its turn to be read. If that is not the case, a buffer is
allocated for the read and the appropriate device strategy routine is
called. *

*Bio.c/breada does not wait (yet) for the read to complete. Rather, it goes
through a similar operation for the read ahead block "rablkno".
Bio.c/incore is called to search the free list of buffers ("bfreelist") to
see if the block was read in a previous read operation. Nothing will be
done, of course, if the read ahead block is in memory. If it is not in
memory, bio.c/getblk is called to search the device queue for it or to
allocate a block so that it may be read. The device strategy module is
called to read the read ahead block, however, the buffer will be marked
(B_ASYNC in "b_flags") so that when the read completes the buffer is
returned to the pool of available buffers. Bio.c/breada then waits for the
read of the the desired block to complete. It does not wait for the read
ahead block . *

*An external variable "raflg" is available for turning off all read ahead
on alldevices. "Raflg" is initialized to one, however, by changing it to
zero read ahead is eliminated. As with bio.c/bread any error detection is
done as a result of the interrupt handler indicating an error to
bio.c/lncore and a system error (in "u_error") being posted. These errors
are of no concern to bio.c/breada or bio.c/bread and are used only at
higher levels of software to return errors to the user. *


ᐧ

[-- Attachment #2: Type: text/html, Size: 9108 bytes --]

Re: [TUHS] Origin of the name 'strategy'

[Dave Horsfall]

Is it just me, or do others here also think of bread() when writing 
"bread" on a shopping list?

I've been using Unix since it first appeared in Australia, so I guess I'm 
now permanently damaged :-)

Then again, during a late-night session at work getting a pair of Telebit 
NetBlazers to work, $BOSS asked me to order a pizza for us, so I picked up 
the phone and started dialling an IP address...  And according to aus.net 
(I think) I was not the only one to do that :-)  Oh, and I got to stay 
overnight in a nearby motel on his sixpence, because I was simply too 
buggered to make the 70km drive back home...

-- Dave

Re: [TUHS] Origin of the name 'strategy'

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Wed, Jan 9, 2019, 12:43 AM Dave Horsfall <dave@horsfall.org wrote:

> [snip]
>
> Wasn't it Mark Twain who said "Two nations divided by a common language"?
>

Apocryphal, actually, but based on a line from one of George Bernard Shaw's
plays.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

Re: [TUHS] Origin of the name 'strategy'

[Dave Horsfall]

On Tue, 8 Jan 2019, Warner Losh wrote:

> The name seems obvious because I've seen it for the last 30 years. But 
> I've not seen it used elsewhere, nor have I seen it documented except in 
> relationship to Unix. It could have been called blkio or bufio or bio or 
> even just work or morework and still been as meaningful. VMS uses the 
> FDT table to process the IRPs sent down. RT-11 has a series of entry 
> points that have boring names. Other systems have a start routine 
> (though more often that is a common routine used by both the queue me 
> and isr functions). There is a wide diversity here...

I must admit that this is an interesting thread, just as long as it wasn't 
called XXoptimize() unless you wanted a backlash from British English 
speakers :-)

In hindsight I suppose that XXstrategy() is obvious, but back then, as you 
ask?  Dunno, but Ken might (if he's reading this thread).

One of my favo[u]rites is sched(); some pronounce it as "shed" and others 
as "sked".  Another American/British thing, I think...

Wasn't it Mark Twain who said "Two nations divided by a common language"?

I no longer have my Lions books on me, sadly enough (lost in a house move) 
but there certainly were some peculiar names in the kernel...

ObGripe: Could anyone replying to the digest version please take the 
trouble to update the Subject: line accordingly?  I've now put the 
original back as a courtesy to others, but I shouldn't have to; it's as 
bad as top-posting.

-- Dave