Risc System/6000

[Charles Hedrick]

>My own personal opinion is that geometry based filesystems are
>getting to be a bad microoptimization.

You might want to separate issues of placement and command sorting.
If the disk controller is prepared to reorder transactions, and does
so well, then I agree it's a mistake for the kernel to do so.  It
should just get transfer requests to the controller as quickly as
possible.  The controller is in a better position to know what the
heads are doing.  

However it probably still makes sense for the kernel to try to place
blocks of files in positions that require minimal effort to read.  I
don't know of any controllers that are prepared to take over
management of the file system.  (In fact even the capability to
reorder transactions doesn't seem to be present in most SCSI
controllers that are actually available.)  It's not clear how much
this requires the kernel to know about the disk geometry.  My
suspicion is that the standard BSD file placement code gains something
even if it doesn't know where the exact track boundaries are.  At
least it will tend to keep files reasonably compact.  This assumes
that SCSI controllers will map logical to physical addresses in a
monotonic fashion, even if it can't be exactly linear.  (Apparently
some do a better job of this than others.  I take this into account
when buying disk drives.)