Xref: utzoo comp.unix.aix:737 comp.periphs.scsi:178
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uakari.primate.wisc.edu!ames!pacbell!dplace!oblio!alruna!mats
From: mats@alruna.UUCP (Mats Wichmann)
Newsgroups: comp.unix.aix,comp.periphs.scsi
Subject: Re: SCSI hiding geometry
Message-ID: <106@alruna.UUCP>
Date: 13 Mar 90 23:01:57 GMT
References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> <132788@sun.Eng.Sun.COM> <1990Mar11.045128.17732@ico.isc.com>
Followup-To: comp.unix.aix
Organization: Wichmann & Associates, Berkeley CA
Lines: 73

mjacob@wonky.Sun.COM (Matt Jacob) writes:

>>...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.

rcd@ico.isc.com (Dick Dunn) writes:

>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.

>Frankly, I don't want to trust J Random Microcoder to give a disk-write-
>reordering algorithm that won't screw things up.  Even if I'm assured of
>some sort of "fair" algorithm, trying to sequence things in the kernel to
>compensate for all the possible variants of reordering sounds like a pain.
>(It's also redundant in a perverse way:  You have to write code to un-do
>decisions which are going to be made for you that you don't want.)

>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.

Smart is in the eyes of the beholder.  Microcomputers still suffer from I/O
problems, compared to "big" machines.  One commonly quoted "difference"
between micros and big iron is that micros still wait for the the right
sector to come around before reading it. Big Iron always has the I/O system
doing something.   So say you want to build a controller that takes a
request, seeks to the right track, and starts pulling data into the buffer
right there, up until the right sector spins around.  That doesn't cost you
anything more - otherwise you just wait - and it might gain something.
Then, just for kicks, if there is no other pending request, or if another
request in the queue is in the same area, you can go on and read the rest
of the track.  If there is something more important to do, you go do that
right away (we built such controllers at Dual Systems long ago (long ago?
six years?) - where, incidentally, Matt Jacob also worked).

That's not a "geometry-based file system" (although you can do things to
your file system to make this scheme work bettter), but its' something you
can't do on SCSI because your controller (Host Adaptor, to be more precise)
doesn't get to know enough about the geometry.  Instead, you have decide
ahead of time which sector numbers you want and ask for them; can't ever
pull the trick of reading _before_ the target sector.  Maybe that idea
isn't really current any more; I've also worked with some controller people
who felt that the "only thing that mattered" was getting data into the
kernel buffer cache as quickly as possible - bypassing controller buffering
except a small amount to serve as a FIFO.  So no value judgement here...

What worries me, like Dick, is that in SCSI, the real "controller" is on
the drive.  If Imprimis or whoever decides to make a drive that they expect
to sell the vast majority of to the UNIX-box market (whatever that is), and
they hire programmers (and specifiers) who really understand what that
market is, maybe we get something that matches the needs of a UNIX vendor.
If he thinks that 92% of his drives are going to go into DOS or OS/2
machines, we don't.  Then you start worrying about different groups within
the "UNIX market" - traditional AT&T filesystems, BSD "Fast" File systems,
file systems enhanced for "commercial" use (TP, and such like).  Do you
really want to leave this up to the drive vendors, rather than people like,
say, Interphase, who supposedly has more detailed expertise about a smaller
segment of the overall drive market?

>Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
>   ...Relax...don't worry...have a homebrew.
Mmm, good idea. I've still got some of that Black Death Stout in the back...

-mats wichmann