From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 3601cff5 for ; Wed, 9 Jan 2019 20:52:54 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id AA66293D29; Thu, 10 Jan 2019 06:52:53 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EAA6793D07; Thu, 10 Jan 2019 06:52:20 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="K1F8jrBD"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A9C8F93D07; Thu, 10 Jan 2019 06:52:17 +1000 (AEST) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by minnie.tuhs.org (Postfix) with ESMTPS id 7BEE593D06 for ; Thu, 10 Jan 2019 06:52:16 +1000 (AEST) Received: by mail-wm1-f53.google.com with SMTP id p6so9777781wmc.1 for ; Wed, 09 Jan 2019 12:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I3qWEBXLCrg+g2eyWsAXE9huM5Q2WAG/mepgSM6hegI=; b=K1F8jrBDM4UL8rBM5hMGQmBFx+1E9yeiJSvwGD26+WH7BZDy8qO/0kXsmT/6atVmEB nVtdJcIiNnNBLNMHwKKMybjvod8MURCKqsRP3//YcmH3NbubDbWPD2CF79tk48D7/ZKn ysj3Vof43TPJo5rPnGZmEMaILzSwIptyMiCq8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I3qWEBXLCrg+g2eyWsAXE9huM5Q2WAG/mepgSM6hegI=; b=MqAwX2kDSuCuEvnb9bk7GNv6hB+AW4I6EnocgnAqR7069Hw/tF5tNvFerDXiyr1Z+U SbQxb6oDe9FZoBpMCkEo22tCa6qkdPfMzRWeKmfGYG0KIlV9m8qmaSRhFfeoubYSJIn6 V6YPy2B94TV1QuStMvtgMNkvn3xCTte/zIgMUg+uTyf8csplq7YSZ/KsAGphMugdW7Ej Wtks9VYt5D4U/Y5VeosS1YEdquH3MJ8dYIVpHqGeoY+tRb0UWCkK11rrol5jX+T5/tCW W/b710ePsTErET/TW/5K0oYv9hPW3gIPbP8T8fF6ZsB7WW3NG4Rao/LH3F4CAoA/NL9u V5JA== X-Gm-Message-State: AJcUukfQcNHXBKFqYf5zNyGq3yUGW/uXHznDMDd7MCGONo140kUjbeXj W4HVml5IiMwHk2ogizWqyrPcpekjfTu3Gpq8oR+10dVxW6xAUg== X-Google-Smtp-Source: ALg8bN6rsERA1ke2d1WAcfG4huPZl4AVhoWkDfJpeOHje/7CiaowWAzJsq1WXJu+Y9bQ/9shOPqTC9sKM7TEB85s7k4= X-Received: by 2002:a1c:aa0f:: with SMTP id t15mr6968171wme.108.1547067134516; Wed, 09 Jan 2019 12:52:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Clem Cole Date: Wed, 9 Jan 2019 15:51:48 -0500 Message-ID: To: Warner Losh Content-Type: multipart/alternative; boundary="000000000000ff38e1057f0ca2e4" Subject: Re: [TUHS] Origin of the name 'strategy' X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000ff38e1057f0ca2e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable below.... On Mon, Jan 7, 2019 at 4:22 PM 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 jus= t > 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=C2=B7 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. * =E1=90=A7 --000000000000ff38e1057f0ca2e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

below..= ..

On Mon, Jan 7, 2019= at 4:22 PM Warner Losh <imp@bsdimp.co= m> wrote:
So what's the origin of the name 'strategy'= =C2=A0 for the I/O routine in Unix that drivers provide? Everything I'v= e 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:=C2=A0 =C2=A0Warren has a scan of the 1976 USG doc= ument:=C2=A0 =C2=A0"UNIX Program Description"=C2=A0 Program Gener= ic PG-1C300 Issue 2
From the section called:=C2=A0 BIO01 - Block I/= O, on the 5th page I think=C2=A0 there seems to be a hint of why it was cal= led strategy.=C2=A0 =C2=A0Under the description of the breada routine are t= he words:=C2=A0

<= div>
Read ahead is a technique whereby= an attempt is made to anticipate where the next read request on a device w= ill 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. The= re 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 bei= ng=C2=A0read from=C2=B7 the device. Smaller amounts of data could be read i= f a program requested it, however, since disks transfer times are small in = comparison to positional and rotational latency times, any extra transfer i= s inconsequential. Also, most DEC disks are designed around a 512 byte sect= or 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 byte= s, any subsequent read or write which references data within that block wil= l 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=C2=A0requests to bring data int= o 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 sho= uld be discontinued so that superfluous reads are not generated.
<= /div>

<= div class=3D"gmail_default">= The strategy adopted under UNIX is to pursue read ahead as long as a proces= s is reading (512 byte blocks) sequentially through a file or a device. Whe= n the first non sequential read is requested, read ahead is discontinued an= d is not restarted until sequential accesses begin again.=C2=A0<= /div>

=
Bio.c/breada carries out t= he read ahead operation. Starting and stopping read ahead and determining w= hich block number in a file or on a device is the read ahead block ("r= ablkno") is done by the higher level function rdwri.c/readi.=C2=A0=
=

=
In implementing th= e 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&quo= t;, 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 roadbl= ocked 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/br= ead 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 th= at is not the case, a buffer is allocated for the read and the appropriate = device strategy routine is called.=C2=A0
=

Bio.c/breada does no= t wait (yet) for the read to complete. Rather, it goes through a similar op= eration for the read ahead block "rablkno". Bio.c/incore is calle= d 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 cours= e, if the read ahead block is in memory. If it is not in memory, bio.c/getb= lk is called to search the device queue for it or to allocate a block so th= at it may be read. The device strategy module is called to read the read ah= ead block, however, the buffer will be marked (B_ASYNC in "b_flags&quo= t;) so that when the read completes the buffer is returned to the pool of a= vailable buffers. Bio.c/breada then waits for the read of the the desired b= lock to complete. It does not wait for the read ahead block .=C2=A0

An external variable &q= uot;raflg" is available for turning off all read ahead on alldevices. = "Raflg" is initialized to one, however, by changing it to zero re= ad 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.=C2=A0

<= /div>

3D""=E1=90=A7 --000000000000ff38e1057f0ca2e4--