From owner-freebsd-current Tue Sep 15 02:37:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA27800 for freebsd-current-outgoing; Tue, 15 Sep 1998 02:37:33 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from word.smith.net.au (castles317.castles.com [208.214.167.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA27738; Tue, 15 Sep 1998 02:37:13 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.9.1/8.8.8) with ESMTP id CAA00565; Tue, 15 Sep 1998 02:40:07 -0700 (PDT) (envelope-from mike@word.smith.net.au) Message-Id: <199809150940.CAA00565@word.smith.net.au> X-Mailer: exmh version 2.0.2 2/24/98 To: dg@root.com cc: Terry Lambert , joelh@gnu.org, tom@uniserve.com, gpalmer@FreeBSD.ORG, irc@cooltime.simplenet.com, freebsd-current@FreeBSD.ORG Subject: Re: Download of FreeBSD 3.0-SNAP In-reply-to: Your message of "Mon, 14 Sep 1998 19:22:52 PDT." <199809150222.TAA23732@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Sep 1998 02:40:05 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> >Note that David points out that FreeBSD *does* do elevator sorting; > >> >it's still not optimal, however, since physical and logical cylinder > >> >boundaries are infrequently the same on modern hardware. > >> > >> FreeBSD's disksort function sorts by block number, not by cylinder number. > > > >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). > > Uh, I think it is reasonable to assume that disk drives have contiguous > block numbers (except for replacement blocks of course). Sorting by block > number is the most optimal way of sorting that we can do in FreeBSD. I don't think anyone would disagree with this; my point was simply that disks are effectively nondeterministic, so by definition you can't have an "optimal" solution. I've seen assorted drive literature describing different caching policies on modern drives, and I think it's probably in our interest not to try too hard to outsmart the disk these days, as it's busy trying to outsmart us. If you really wanted to play games with the queue sorter, you might want to go for a minimal distance insertion policy rather than a strict ladder sort. As Kirk pointed out, there's plenty of room for experimentation in this field. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message