phil@amdcad.AMD.COM (Phil Ngai) (05/21/87)
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.
--
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.commats@forbrk.UUCP (05/23/87)
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
martyl@rocksvax.UUCP (Marty Leisner) (06/01/87)
In article <324@forbrk.UUCP> mats@forbrk.UUCP (Mats Wichmann) writes: >SCSI is an essentially low-performance peripheral interface. Its' main >advantage is ease of integration of new peripherals. I was under the impression SCSI could transfer data at several megabytes/ second (1.5-4? depending on whether it is asynchronous or synchronous?) This sounds pretty high performance to me. What CPU can eat data that fast? >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). Is this a problem with the interface or the boards being built for it? If caching is done on both ends (host adapter and disk controller) and with a low performance microprocessor on each end, it looks like impressive performance could be achieved. Whenever a read request is made to disk, the process needing the data has to hang on the disk access anyway -- once the request is initiated, the host cpu shouldn't be bothered with the pending request until it receives acknowledgement the operation is complete. From a device driver point of view, I like to pass linear sector numbers to the controller and let the controller figure out the head/track/sector. Also, SCSI appears to have the capability to do interesting things with multiple hosts sharing multiple disks (I'm thinking of buying a SCSI disk for my PC AT at work). marty leisner xerox corp leisner.henr@xerox.com martyl@rocksvax.uucp
mats@forbrk.UUCP (06/15/87)
In article <1142@rocksvax.UUCP> martyl@rocksvax.UUCP (Marty Leisner) writes: >In article <324@forbrk.UUCP> mats@forbrk.UUCP (Mats Wichmann) writes: >>SCSI is an essentially low-performance peripheral interface. Its' main >>advantage is ease of integration of new peripherals. > >I was under the impression SCSI could transfer data at several megabytes/ >second (1.5-4? depending on whether it is asynchronous or synchronous?) >This sounds pretty high performance to me. What CPU can eat data that >fast? Peak burst transfer rates can indeed be in the 3-4 MB range, if you use the synchronous option which I haven't seen implemented yet. Disk type devices have all been in the 5 to 10 megabit transfer rate range. Really not a problem with the spec per se, but with the fact that the spec was introduced so as to encourage the use of existing technology - ST506-type disk drives. This was a necessity for accepance, but.... >>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). > >Is this a problem with the interface or the boards being built for it? > It is, of course, a problem with the boards being built - but sort of with the interface itself. Let me explain what I mean: a lot of performance can be gained by doing a real bang-up job on the controller which is on the drive's end of the SCSI. This puts the job of building a high-performance controller with people who have not done it before (and who may perhaps not have much interest in it): the drive manufacturers, and away from companies who have made a living from disk controllers - people like Emulex, Xylogics, and even Dual (whom I used to work for). This is not necessarily a "good thing". >If caching is done on both ends (host adapter and disk controller) and with >a low performance microprocessor on each end, it looks like impressive >performance could be achieved. Whenever a read request is made to disk, >the process needing the data has to hang on the disk access anyway -- once >the request is initiated, the host cpu shouldn't be bothered with the >pending request until it receives acknowledgement the operation is complete. >From a device driver point of view, I like to pass linear sector numbers to >the controller and let the controller figure out the head/track/sector. > I really don't argue with this reasoning, although someone needs to convince the drive mfgs. to put intelligent caching on their drives, which is something that will be driven by demand. As Fortune, we are not in any position to make these demands; and everytime we say something to CDC or Micropolis, they tell us nobody else has ever asked for that, so the demand must not be out there yet - maybe never will be. The type of intelligence I am looking for, is filling of buffers while nothing else is going on - i.e., soaking up dead time, waiting for the heads to get to the right sector, etc. The kind SCSI mfgs. are doing now causes the original request to often take longer to be satisfied. >Also, SCSI appears to have the capability to do interesting things with >multiple hosts sharing multiple disks (I'm thinking of buying a SCSI disk >for my PC AT at work). > It does that, although from reading (not from actually implementing) it appears that the "reserve" functions are not especially useful, which means that there will be some logistical problems with sharing disks - I wouldn't feel comfortable sharing anything that wasn't effectively "read-only". In all, Marty made me think of things in a slightly new light. I am still not really too thrilled about SCSI, but it is a little hard to justify, in an absolute sense, my views that SCSI is inherently low-performance. Instead, I now feel that the implementation approach, which makes many of the high-performance features optional, along with the way the standard has been introduced, while not in and of themselves bad things, doom SCSI to *effectively* be low performance in most cases. Mats