Xref: utzoo comp.unix.aix:709 comp.periphs.scsi:138
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.unix.aix,comp.periphs.scsi
Subject: SCSI hiding geometry
Summary: who's in control?
Message-ID: <1990Mar11.045128.17732@ico.isc.com>
Date: 11 Mar 90 04:51:28 GMT
References: <1660@aber-cs.UUCP> <51507@sgi.sgi.com> <132788@sun.Eng.Sun.COM>
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 49

Carrying on the discussion about SCSI hiding drive geometry...(I see
comp.periphs.scsi is in the discussion; should we also move it out of
.unix.aix to something more general?)...

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.

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

>...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.
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.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Relax...don't worry...have a homebrew.