Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ptsfa!dual!forbrk!mats
From: mats@forbrk.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Berkeley FFS and SCSI
Message-ID: <324@forbrk.UUCP>
Date: Sat, 23-May-87 14:54:10 EDT
Article-I.D.: forbrk.324
Posted: Sat May 23 14:54:10 1987
Date-Received: Thu, 28-May-87 06:40:37 EDT
References: <16753@amdcad.AMD.COM>
Reply-To: mats@forbrk.UUCP (Mats Wichmann)
Organization: Fortune Systems/SCI Technology Inc. (Berkeley, CA)
Lines: 72

In article <16753@amdcad.AMD.COM> phil@amdcad.AMD.COM (Phil Ngai) writes:
>
>I was wondering how the Berkeley fast filesystem, with its knowledge
>of cylinder groups etc interacted with SCSI disks, where blocks are
>logical numbers and (often) no information is available on track and
>cylinder sizes and the like. 

SCSI is a very interesting beast. The following comments are very much my 
own opinion; as a company we are quite firmly committed to SCSI.

SCSI is an essentially low-performance peripheral interface. Its' main
advantage is ease of integration of new peripherals. This is not to be
denigrated as an advantage - for example, we got in a brand-new 125MB
embedded SCSI tape streamer from Archive, and all it took me to get it 
running was to unteach the driver some non-standard tricks it had been 
taught to talk to an Adaptec SCSI-to-QIC02 converter (really only one trick).
Took me the time to connect the cables to get it working tolerably
well, and a couple of hours with the driver to get it working really well.
And some customers of ours who knew essentially nothing about UNIX drivers
got a SCSI optical disk running pretty quickly (once we taught our
controller firmware to accept Group 1 commands - the original designer
had neglected that). Most other stuff (disk drives) have been "just
plug it in".

You pay for this, however. First of all, it is considered a benefit that
the drive takes a block number and goes to the right place without your
having to decompose it into a track-head-sector triple. But if you think 
about it, you have just farmed out the work that your neato 16 or 25 or 
whatever MHz processor could have done, probably with hardware arithmetic, 
to a small dedicated processor on the drive which has nowhere near the 
arithmetic capabilities. Interesting tradeoff, eh?

My biggest problem with SCSI is that you are too far removed from the disk. 
I would *like* my disk controller to buffer lots of data, and preferably 
to keep reading stuff and storing it away while there are no other requests 
pending (non-intrusive readahead). Most good SMD controllers, for example,
do something like this these days. To buffer data on SCSI, however, I have 
to ask the drive to send back more than just the one block I wanted, and 
this means that if another request comes in quickly, there will be a delay
while I bring in this big chunk of data (intrusive readahead). Quantum does 
make a drive which has a cache on its controller, but it suffers from pretty
much the same problem - you program it how much to read ahead, and it won't 
accept the next command until it has finished (our tests indicated that the 
cache on the Quantum could be tuned to give significantly better performance 
on some applications; but always at the cost of poorer performance on others. 
Tuning such a drive would need to be done on a per-site basis, perhaps 
dynamically, based on statistics kept on usage profile - yuck!).

My opinion is that requirements for high-performance disk subsystems are
best met throught some other arrangement, and should not be sharing a
controller (and 8-bit data bus, which the SCSI is!!!) with other devices;
and that the ideal use for SCSI in systems with such requirements is to
improve connectivity and configurability, and to provide a vehicle to 
interfacing to medium-performance peripherals such as optical disks, 
laser printers (when they get around to adding that to the spec), etc. 

To address the original question, however, there should be no particular
problem with the Fast File System on a SCSI drive. The information as to 
tracks-heads-sectors can usually be obtained from the drive itself; if not 
you can always read the manual. Most drives will hopefully adhere to this 
by hiding media flaws in the formatting rather than slipping them (a fictitious
example: block 100 will always map to the track-head-sector triple 0-4-0, 
and not be mapped to the triple 0-4-1 if there was a bad block on block 74,
causing every subsequent block to move up by one).  In general, the newer, 
embedded SCSI drives are doing this, while the "pseudo-SCSI" implementations -
ST-506 drive plus a converter board - don't.  Anyway, once you have the 
information, you can build your cylinder groups when you do your mkfs, and 
after that, everything should run just fine.  You just have to defeat the 
hiding of the drive characteristics that one time.

Mats Wichmann			hplabs!fortune!forbrk!mats
				ucbvax!{dual,mtxinu}!forbrk!mats