From owner-freebsd-current  Tue Sep 15 13:12:27 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA22403
          for freebsd-current-outgoing; Tue, 15 Sep 1998 13:12:27 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22221;
          Tue, 15 Sep 1998 13:11:56 -0700 (PDT)
          (envelope-from tlambert@usr09.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id NAA01358;
	Tue, 15 Sep 1998 13:11:30 -0700 (MST)
Received: from usr09.primenet.com(206.165.6.209)
 via SMTP by smtp03.primenet.com, id smtpd001267; Tue Sep 15 13:11:21 1998
Received: (from tlambert@localhost)
	by usr09.primenet.com (8.8.5/8.8.5) id NAA22785;
	Tue, 15 Sep 1998 13:11:12 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199809152011.NAA22785@usr09.primenet.com>
Subject: Re: Download of FreeBSD 3.0-SNAP
To: rb@gid.co.uk (Bob Bishop)
Date: Tue, 15 Sep 1998 20:11:12 +0000 (GMT)
Cc: tlambert@primenet.com, dg@root.com, joelh@gnu.org, tom@uniserve.com,
        gpalmer@FreeBSD.ORG, irc@cooltime.simplenet.com,
        freebsd-current@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.96.980915113818.18739A-100000@seagoon> from "Bob Bishop" at Sep 15, 98 11:44:56 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > Hence it being non-optimal; see Mike's post... optimial is "always does
> > exactly the right thing".  It's not pessimal, either (as Mike pointed
> > out, too).
> 
> What's "exactly the right thing" though? If you have two I/O limited
> processes trying to access opposite ends of the disk, you probably max out
> the throughput by preferring the transfer closest to where the heads
> currently are. This will almost certainly result in the 'unlucky' process
> getting I/O starved, which may not be acceptable.

Which is why you gather to increase data locality, instead of
elevator sorting to decrease seek latency.  You want to optimise for
getting pages in and out of core (i.e., minimal average latency for
and random sampling of N out of M pages, for N<<M), not for the
longest possible life expectance of the head positioning voice coil.

Seeks are relatively much less expensive, since, as Poul pointed out,
the sectors are inversely ordered to optimize reads.  Most server
operations are reads (one Novell study states that as much as 70%
of all disk activity is file or directory reads, 12% is writes, and
8% is all other operations combined).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message