Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Nov 1995 23:11:51 -0800 (PST)
From:      Julian Elischer <julian@ref.tfs.com>
To:        davidg@Root.COM
Cc:        uhclem%nemesis@fw.ast.com, simonm@dcs.gla.ac.uk, current@freebsd.org
Subject:   Re: Disk I/O that binds
Message-ID:  <199511140711.XAA26748@ref.tfs.com>
In-Reply-To: <199511140549.VAA04329@corbin.Root.COM> from "David Greenman" at Nov 13, 95 09:49:48 pm

next in thread | previous in thread | raw e-mail | index | archive | help
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
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511140711.XAA26748>