Xref: utzoo comp.unix.aix:701 comp.periphs.scsi:135
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!texbell!texsun!newstop!sun!wonky!mjacob
From: mjacob@wonky.Sun.COM (Matt Jacob)
Newsgroups: comp.unix.aix,comp.periphs.scsi
Subject: Re: Risc System/6000
Message-ID: <132788@sun.Eng.Sun.COM>
Date: 10 Mar 90 08:35:25 GMT
References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> <PCG.90Mar2184300@rupert.cs.aber.ac.uk> <1990Mar9.022931.4674@world.std.com>
Sender: news@sun.Eng.Sun.COM
Reply-To: mjacob@sun.UUCP (Matt Jacob)
Organization: Sun Microsystems, Mountain View
Lines: 30

In article <1990Mar9.022931.4674@world.std.com> madd@world.std.com (jim frost) writes:
>pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes:
>>This is the notorious problem that SCSI will hide from the OS the drive
>>geometry (down to sector remapping, wich can be really nasty), which of
>>course pays put to many nice optimizations.
>
>It's not all that difficult to determine the geometry of a SCSI drive.
>During the last USENIX a BSD person who's been researching FS
>optimizations which take into account rotational latency hinted that
>the BSD people have done so.  What you do with SCSI, then, is run a
>geometry analyzer which dumps out the configuration of the SCSI drive
>so that the filesystem can do the apropriate optimizations.  No big
>trick there.
>
>jim frost
>saber software
>jimf@saber.com

Umm- it would be interesting to see whether they claim to be able
to make sense out of variable geometry (bit-zone recording method)
drives.

My own personal opinion is that geometry based filesystems are
getting to be a bad microoptimization. With the coming of SCSI-2
multiple command targets, it seems to me that one should just
concentrate on getting requests out to the target as quickly
as possible and let the microprocessor on the drive figure out
the best order do them in.

-matt jacob