From owner-freebsd-current Mon Nov 13 23:13:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03628 for current-outgoing; Mon, 13 Nov 1995 23:13:29 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA03617 for ; Mon, 13 Nov 1995 23:13:27 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA26748; Mon, 13 Nov 1995 23:11:53 -0800 From: Julian Elischer Message-Id: <199511140711.XAA26748@ref.tfs.com> Subject: Re: Disk I/O that binds To: davidg@Root.COM Date: Mon, 13 Nov 1995 23:11:51 -0800 (PST) Cc: uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org In-Reply-To: <199511140549.VAA04329@corbin.Root.COM> from "David Greenman" at Nov 13, 95 09:49:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1263 Sender: owner-current@freebsd.org Precedence: bulk Another answer may be in the way we allocate blocks on the disk.. maybe we should allocate less on any particular cylinder group and jump around more often??? (might be an easier answer :) > >however, a 5 Second wait would imply reading about 25MB of data! > >(though I guess a process that neads to do 10 reads needs to get past this hog > >10 times before being able to proceed (it might be getting little bits > >of disk at a time. > > Only if you have very fast disks...which explains why people like me don't > see the problem very often, and when I do see it, it's not serious enough to > be a "problem". People with slow disks (IDE) will see the problem magnified > significantly. > For fairness, I think the queue depth for each chunk needs to be limited to > less than 10 requests. It should be tuneable so that we can experiment with > different values. For the moment I can write a patch that will disable the > sorting in disksort - people experiancing the "hang" problem should try the > patch when I make it available and see if the problem goes away. ...Of course > disk performance will suffer unless you're using SCSI with tagged queueing (in > which case the drive does the ordering - usually much more intelligently). > > -DG >