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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,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 aa8d9b27 for ; Wed, 9 Jan 2019 05:46:18 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id F03B7A35D5; Wed, 9 Jan 2019 15:46:16 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 913A9A35C4; Wed, 9 Jan 2019 15:45:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="hi1qVqLp"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id EA8CFA35C4; Wed, 9 Jan 2019 15:45:44 +1000 (AEST) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by minnie.tuhs.org (Postfix) with ESMTPS id E5E64A35B7 for ; Wed, 9 Jan 2019 15:45:43 +1000 (AEST) Received: by mail-qt1-f178.google.com with SMTP id l12so7122054qtf.8 for ; Tue, 08 Jan 2019 21:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GiJ6Q6q60ksrAiNRQSrPTNcZC8cJQm8mWjrKjmHi/LI=; b=hi1qVqLpo3gxfIvrkg0AvAbLsnoRBYK/aRNSEL6BnGFBt2mD6/+GvW9Dxe1XoUf7y5 B9TY0D1bEaXYgxFP7qgS/hyf+s1KX6nqpK0VAMNkmKaEHsXJqXIOTFsV99FdB9OtDEBH JgzwtrZ9WRp1YDtZdrkAhVIGpX5N1LWnFcYp1G00yhS9KHw/Paj00QlIDVLzBC9JtMfA S4DwVNKT5O8l1qEhlQUJ7jLNd9hl2ZahqGLjjh+JJE1pxS+/3fZhrtfVNhsABM6jtoJw WTKXOVf2F3PpDdimwOfCOCL4dpRcwH58kRTiUzMOJrx6BFG6mhNo6lyrJYJLWLEvt9Ck TIyg== 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=GiJ6Q6q60ksrAiNRQSrPTNcZC8cJQm8mWjrKjmHi/LI=; b=oyhmbx+i7yOlg/t4gSpALGiTGowk8FKU0UGxqEWuzyXDpsDeA5JWG9b2rpgqo8MWE+ +ApqH4d8HDZmLr+eebKFE+vGG3RS0CHSP5P/ftlnO1VIDF86Ew/lNy/tE1vKtRleUoHr NSYu+yr5M0tc6nV+72/4Cvo0I0Ak1Ece1GsxO9RO09PwWXhs8gNZJdM1oEsEXCjzzRZ3 1GaH+nIIixxcHlUkghAhGvDzZVcFQCVTMFGMf69Tam5wBuPuFXmpQk4/uchfCduGF/lx LG2bVDil9kW+BdzFVvSGqWSX6f4XLkh3lf9OqpzHjhxpS/2ZjzkGcG6DZmwsPm/zJTZL RGVg== X-Gm-Message-State: AJcUukd8bxA/ttZh40rv9xQ1k9PUlB3D/ciFkkUgm1YFHfzH5zouGDdQ Mh5I8ucprOTXlPWvn+4P+fHX5pirOwEhutahJEHVMw== X-Google-Smtp-Source: ALg8bN4dsDS8aOj4qBcl6S+eokKMq1OHCIBV5xc5JVjPyoV59pOzfLy0BKdf8s/dE2MLPBfPPZW/LCbWNKp6iFffIuM= X-Received: by 2002:a05:6214:1087:: with SMTP id o7mr4526588qvr.115.1547012742861; Tue, 08 Jan 2019 21:45:42 -0800 (PST) MIME-Version: 1.0 References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> <20190109052004.9DB6F156E410@mail.bitblocks.com> In-Reply-To: <20190109052004.9DB6F156E410@mail.bitblocks.com> From: Warner Losh Date: Tue, 8 Jan 2019 22:45:31 -0700 Message-ID: To: Bakul Shah Content-Type: multipart/alternative; boundary="000000000000006948057efff96f" Subject: Re: [TUHS] TUHS Digest, Vol 38, Issue 10 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" --000000000000006948057efff96f Content-Type: text/plain; charset="UTF-8" On Tue, Jan 8, 2019 at 10:20 PM Bakul Shah wrote: > On Wed, 09 Jan 2019 13:10:18 +1100 Dave Horsfall > 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. > Speaking of origins, it's in the V4 nsys (pre V5) sources we have. It's not in the V1 or V0 sources we have. I could find no comments in the V4 stuff or the V5 stuff to give its origin tale. > 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. > Yes. Many OSes have factored this out so the code can be shared among the (now wide variety) of devices out there, as well as tuned for different work loads. > > 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. > For floppy drivers that I've seen the source to in early unixes, this was often the case. One minor device would be to access the 'raw' device, while another would be to access the 'cooked' sector numbers where the mapping was anything but linear. you'd have an interleave of, say, 4 or so, and then a 'slip' from track to track. The interleave factor was based on how much time it took for (a) the disk to rotate and (b) for the OS to process the sector (plus a little) and the 'slip' from track to track was based on rotational time and seek time so that when you were doing a sequential workload the first logical sector in the next track would quickly be under the read head... All of this was done in the floppy driver. But there were some drawbacks to this that became clear as a number of different technologies to access the drive were developed. When you have 6 different floppy controllers, it makes sense to abstract out the bits that are common to all floppies. When you have 200 disk controllers in 20 different drivers, it makes sense to add a disk layer in there. Add to that partitioning schemes that are nested, and you quickly realize you don't want to implement all that in every driver... One of the brilliant decisions in Unix was to leave all this to the driver and not have the OS get in the way.... But it was also one that no modern unix or unix-like system still does due to the extreme diversity of block devices in the market place today. There are thousands, where the original unix had maybe a half dozen different ones if you squinted just right... At least disksort() was abstracted out into a library.. Warner --000000000000006948057efff96f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 8, 2019 at 10:20 PM Bakul Shah <bakul@bitblocks.com> wrote:
On Wed, 09 Jan 2019 13:10:18= +1100 Dave Horsfall <dave@horsfall.org> wrote:
Dave Horsfall writes:
> On Tue, 8 Jan 2019, Warner Losh wrote:
>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0i understood that this implemented the = elevator algorithm, and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0possible rotational latency compensatio= n.
> >
> >
> > I know what it does. I want to know why that specific name was se= lected.
>
> 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 th= e
> sectors, depending upon the device?=C2=A0 I'm not being snarky, bu= t it seems
> like an obvious choice (if not a hint) to me...
>
> Let's see, I need a strategy to optimise access, taking into accou= nt
> seek and rotational latency.=C2=A0 I know!=C2=A0 I'll call it XXst= rategy()!

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.=C2=A0 My guess is the<= br> original author who named it strategy had this in mind.

Speaking of origins, it's in the V4 nsys (pre V5) sour= ces we have. It's not in the V1 or V0 sources we have. I could find no = comments in the V4 stuff or the V5 stuff to give its origin tale.
=C2=A0
But these are not exactly dependent on the vagaries of
individual disk drivers.=C2=A0 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.

Yes. M= any OSes have factored this out so the code can be shared among the (now wi= de variety) of devices out there, as well as tuned for different work loads= .
=C2=A0
> For example, I could envisage a disk where the sectors are deliberatel= y
> not numbered sequentially i.e. they've taken rotational latency in= to
> 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.

= =C2=A0For floppy drivers that I've seen the source to in early unixes, = this was often the case. One minor device would be to access the 'raw&#= 39; device, while another would be to access the 'cooked' sector nu= mbers where the mapping was anything but linear. you'd have an interlea= ve of, say, 4 or so, and then a 'slip' from track to track. The int= erleave factor was based on how much time it took for (a) the disk to rotat= e and (b) for the OS to process the sector (plus a little) and the 'sli= p' from track to track was based on rotational time and seek time so th= at when you were doing a sequential workload the first logical sector in th= e next track would quickly be under the read head... All of this was done i= n the floppy driver.

But there were some drawbacks= to this that became clear as a number of different technologies to access = the drive were developed. When you have 6 different floppy controllers, it = makes sense to abstract out the bits that are common to all floppies. When = you have 200 disk controllers in 20 different drivers, it makes sense to ad= d a disk layer in there. Add to that partitioning schemes that are nested, = and you quickly realize you don't want to implement all that in every d= river... One of the brilliant decisions in Unix was to leave all this to th= e driver and not have the OS get in the way.... But it was also one that no= modern unix or unix-like system still does due to the extreme diversity of= block devices in the market place today. There are thousands, where the or= iginal unix had maybe a half dozen different ones if you squinted just righ= t... At least disksort() was abstracted out into a library..

=
Warner
--000000000000006948057efff96f--