Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!mcsun!uknet!stl!bnrgate!nrcnet0!cunews!torn!cs.utexas.edu!sun-barr!olivea!spool.mu.edu!uwm.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD and IDE drives
Message-ID: <1992Sep23.210231.15155@fcom.cc.utah.edu>
Date: 23 Sep 92 21:02:31 GMT
References: <1992Sep22.224636.13727@spang.Camosun.BC.CA>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
Lines: 66
In article <1992Sep22.224636.13727@spang.Camosun.BC.CA> dbarker@spang.Camosun.BC.CA (Deryk Barker) writes:
>
>This may be a dumb question or may have been asked before, still. Can
>386BSD run on a system with IDE hard drives? I've been told (by a
>dealer) that Unix in general doesn't work properly with IDE, but he
>was unable actually to tell me why.
Terry's diatribe on IDE, geometry translation, and caching controllers:
UNIX implemntations, being in protected mode, can not use BIOS, like DOS, to
do the I/O. This means that there has to be a driver written for each of
the different controllers to be supported. There are a lot of IDE controllers.
Dell has made good headway in supporting a large number of them, but not
all of them are supported by any means.
Geometry translation is a problem in that it blows up predictive read
algorithms and seek offset scheduling and rotational latency based disk
read order optimizations -- basically, about 10% of the speed improvement
to UFS and other UNIX file systems. Since DOS is generally too stupid to
cache from a local hard drive (The client side of NetWare caches if it
turned on; I don't know about LAN Manager, but suspect that it does too,
so this doesn't apply to network drives), this doesn't impact it much.
UNIX, on the other hand, tries to write when the head is nearly in the
desired position... this means it reduces seek and rotational latency,
upping the apparent access rate from a user perspect by arranging for
the hardware to be "coincidently" in the right place for the fastest
access.
With geometry translation, all this wonderful code is worse than useless
-- it's detrimental (unless you can use the *real* disk geometry, like
386BSD tries to do). This is because the sector optimization is based
on the assumption that the disk table for the drive accurately reflects
the physical constraints of the drive, and the optimization is based
on *physical* coincidences to improve timing.
Geometry translation also mucks with the 90% of the speed improvement
available in UFS and other UNIX file systems, which is basically using
larger block sizes on reads an writes. The problem is, adjacent sectors
on the disk aren't really adjacent.
All this geometry translation came out of the 1024 cylinder limit built
into DOS.
Some people argue that a lot of what UNIX does in terms of caching isn't
really needed any more with caching controllers. I don't think this is
going to be true until the data transfer rate from the controller over the
bus is the same as that to "local" (motherboard) memory. Until then, soft
caching should continue to be higher performance.
The bad news is that there are starting to be SCSI drives with translation,
and pretty soon there may be no safe disk technology.
Terry Lambert
terry_lambert@npd.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------