Xref: utzoo comp.unix.aix:710 comp.periphs.scsi:141
Path: utzoo!censor!geac!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.unix.aix,comp.periphs.scsi
Subject: Re: SCSI hiding geometry
Message-ID: <10109@cbmvax.commodore.com>
Date: 11 Mar 90 18:06:47 GMT
References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> <132788@sun.Eng.Sun.COM> <1990Mar11.045128.17732@ico.isc.com>
Reply-To: jesup@cbmvax (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 56

In article <1990Mar11.045128.17732@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
>mjacob@wonky.Sun.COM (Matt Jacob) writes:
>...
>> My own personal opinion is that geometry based filesystems are
>> getting to be a bad microoptimization...
>
>But SCSI is not the only interface around, and I think there are some open
>questions about how much device-sensitivity you want in the mid level of
>the file/disk system.  That is, if you've got a more traditional disk
>interface (some of which are pretty high performance) you need to deal with
>geometry.  Do you want to ignore geometry some of the time?  It gets harder
>and harder to know how/where to make the cut.

	You can easily separate the levels when you have a "traditional" disk
interface.  Under AmigaDos, on the A590 SCSI/"PC Bus Drive" HD interface,
you can send direct SCSI commands to either the SCSI bus, or the "PC Bus"
drives (the driver deals with them).

>(My own personal opinion, not necessarily well substantiated, is that SCSI
>was at best premature, and at worst wrong, in trying to hide drive geometry
>from the host system.)

	Ah, but it doesn't!  Use READ_CAPACITY in the "tell me where the next
slowdown in read is" mode.  This allows you to build a list of groups of
sectors that are "fast", and know where the breaks are.  Note that this 
handles Zone-Recorded drives quite well, while still allowing the FS to
know the geometry (who ever said disks had to be regular arrays? Even the
old PET disks used Zone recording...)

>This raises a sticky issue of who's in control of the disk system.
>Consider reliability issues.  Two examples come to mind.  First, in a UNIX
>file system, you probably want to have some control over the order of
>operations so that you can have some reasonable assurance that operations
>on inodes, indirect blocks, directories, and data happen in a way that will
>allow you a good chance for recovery if you crash while there are
>operations in the queue.  Second, in a database it is essential that you be
>able to control the sequencing of operations so that commits really commit,
>journaling happens when you expect, etc.

	You can still do this under SCSI, though it may be slightly less
simple than straight Read/Write commands (though I think you can force
serialization of writes pretty easily).

>I think it would make the job of kernel folks a lot easier if they could
>deal with interfaces which just attempt to be fast in a predictable way,
>instead of trying to be smart.

	The interfaces are only as smart as you want them to be.  Filesystems
are the "customer" of essentially all SCSI drives; and they're set up pretty
well to make things nice for filesystems (and drivers).  Also, every SCSI
drive I've seen has defaults that are "safe" - no reordering of writes, etc.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"