SCSI hiding geometry

[Dick Taylor]

In article <1990Mar11.045128.17732 at ico.isc.com> rcd at ico.isc.com (Dick Dunn) writes:
>...
>mjacob at 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.
>
>This raises a sticky issue of who's in control of the disk system.
>...
>
>Frankly, I don't want to trust J Random Microcoder to give a disk-write-
>reordering algorithm that won't screw things up. 

And this is the root of the debate.  It's a question of trust and shared 
authority.  It balances the definite benefit of farming out the grunt work
(do you REALLY want per-sector interrupts in the operating system?) against 
the loss of critical control over the order of operations and error recovery.

Multiprocessor systems (and anything that has a CPU and a separate SCSI disk
drive is a multiprocessor system, like it or not) have advantages in speed 
and disadvantages in complexity and potential for trouble.  The disadvantages
are normally mitigated by careful design.  When you're adding a SCSI device
to a UNIX filesystem, however, you're denied a lot of things that would be
useful.

As another poster pointed out, UNIX has certain things (inodes, user database 
information, and so on) where the order of operations makes a critical 
difference.  It also has data where the order of writes may be very 
unimportant.  NONE of this information about the data is passed down through 
the driver level to the drive.  Without that, optimization algorithms can 
make guesses (based on buffer header contents, size and location of requests,
and context within an operation), but the guesses are never guaranteed.  Add 
in the indifferent way that many companies seem to implement their firmware 
and there's not a lot of room for trust.

Nonetheless, there are companies (including one which I used to work for) that
have made a reputation and quite a chunk of change improving the speed of the 
UNIX filesystem.  The benefits, which can be substantial given the partially 
brain-dead way that UNIX generates I/O requests, outweigh the problems.

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

Speaking as a kernel folk, I'd have to agree, with a major addition.  I'd 
rather have a device that's fast than one that tries to be smart.  But I'd 
really rather have one that IS smart and that can take some of the load off 
of my CPU, which has better things to do than optimize I/O requests.

SCSI, good or bad, hides the drive geometry from the kernel.  It also
gives the drive a lot of control over the actual execution of a request.
Given this, I think that Mr. Jacob's original statement is a better way
of thinking about the role of the OS between the filesystem and the drive,
and that we need to concentrate where we can on improving UNIX's ability
to handle a multiprocessor filesystem.