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.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 180874ef for ; Wed, 9 Jan 2019 05:20:51 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2A898A35E9; Wed, 9 Jan 2019 15:20:50 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0C621A35C8; Wed, 9 Jan 2019 15:20:15 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id A2D4AA35C7; Wed, 9 Jan 2019 15:20:12 +1000 (AEST) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by minnie.tuhs.org (Postfix) with ESMTP id 25F21A35B7 for ; Wed, 9 Jan 2019 15:20:12 +1000 (AEST) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 9DB6F156E410; Tue, 8 Jan 2019 21:19:57 -0800 (PST) From: Bakul Shah To: Dave Horsfall In-reply-to: Your message of "Wed, 09 Jan 2019 13:10:18 +1100." References: <966501A7-7736-4EB0-841A-C1516C876272@quintile.net> Comments: In-reply-to Dave Horsfall message dated "Wed, 09 Jan 2019 13:10:18 +1100." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62717.1547011197.1@bitblocks.com> Date: Tue, 08 Jan 2019 21:19:57 -0800 Message-Id: <20190109052004.9DB6F156E410@mail.bitblocks.com> 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" 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. 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.