Frequently Asked Questions List for comp.periphs.scsi
Copyright Gary Field, 1994-2003, all rights reserved, permission granted for non-commercial distribution in un-modified form.
The official resource for finding out those things you always wanted to know about SCSI, but were afraid to ask.
Current Editor: Gary Field (scsifaq@bigfoot.com)
(Where you see reference to [Editor(GF)] that means me.)
Last updated: April 3, 2005
Note: Please allow the whole file to load before clicking on any links. If you click on a link before the portion of the page it points to has loaded, you just get sent to the top of the document.
Occasionally, something I have written strikes controversy, usually either due to a gray area in one of the standards or due to a misintrepretation of what I wrote or included. When I get notified of the disagreement, I research the topic, listen to reasonable arguments, and make the corrections or not as I see fit.
Articles get into the FAQ in several ways:
1) I see a question appear a number of times and write an
answer for that topic and put it in.
2) Someone else writes up an answer for a question they feel
needs answering and sends it to me. I edit it for accuracy
if necessary,
correct the grammar/spelling somewhat, edit the text into a consistent
format, and put it in.
3) I see what I feel is a well written response to a question
posted in comp.periphs.scsi and ask the author if I can include it.
Submitting articles for the FAQ:
If you feel the urge to write up an article for the SCSI FAQ that you
feel qualified to answer, please format it the way the existing articles
are and send it to me, (preferrably in HTML format, but .txt or .doc is
OK too).
Maintained by Johnathan Vail until November 1993.
Maintained by Gary Field from November 1993 to the present.
About the editor:
My credentials in SCSI technology are pretty substantial. I've been
working with this stuff on a daily basis, continuously since 1985 on both
PCs and various UNIX platforms. I write and enhance SCSI device drivers
for a living. All of my own computers use all SCSI I/O.
I also wrote/re-wrote "The Book of SCSI: I/O
for the New Millennium", and wrote the UNIX chapter in Brian Sawert's
book "The Programmer's Guide to SCSI".
There are areas of SCSI which I am not expert on, and when a question of fact comes up in one of those areas, I research the issue using the SCSI standards documents, or, ask my colleagues who are expert in that area, about it.
In general I get nothing but compliments about the FAQ. The most common complaint is that it's not always up to date on certain topics. I try my best to keep it updated, but SCSI marches on...
"Who pays for the "SCSI Info Central" Web site where the FAQ is distributed from"? you ask.
SCSI Info Central
http://www.scsifaq.org/
is my own personal web site that I've registered as scsifaq.org, connected
to the Internet via Comcast cable modem. I spend a considerable amount
of my own time and money maintaining the site, and I hope people benefit
from it.
This has to be the most commonly asked question regarding
SCSI!
I hope this will summarize my thoughts on that issue:
For someone to who doesn't need a real multi-tasking workstation or server, the only reason for paying the extra money for SCSI is flexibility. EIDE/ATA is strictly for "inside the case" peripherals. SCSI allows you to attach a large collection of add-ons like scanners, CD recorders, tape drives (or even devices not conceived of yet), either inside or outside the CPU case in whatever manner suits your needs or wishes.
If you like non-technical analogies:
SCSI is like a palace, with an architecture that was well thought out from the beginning and built upon over a period of time to make it even greater than originally envisioned.
IDE/ATA is like a log cabin, with a dirt floor, built from whatever was found lying around in late Fall just before the snow came. It can't be expanded because it has no foundation and would collapse under its own weight.
Both provide shelter. SCSI costs more (but not as much as a palace :-)).
Take your pick.
If automobile analogies are more to your liking:
A Ford Escort will get you to work just as fast as a Volvo station wagon. Which would you rather go on vacation in? Which would you rather be in if an accident occurs?
If your computer is nothing more than a machine that's only purpose is to perform a certain set of tasks, and you don't expect to want any more out of it, IDE is probably for you.
On the other hand, if you enjoy computing and are always looking for more things your computer can do for you, SCSI will help enhance the experience for you. You won't regret the investment.
Just as with a palace however, you need to learn your way around. That's
where this FAQ comes in!
Where to get the latest copy of this FAQ:
SCSIFAQ.ORG - Now at a browser near you!
I will not include pointers for devices like hard disks, tapes, CDROMs
etc., which I consider readily available.
Categories:
SCSI Performance Determination and Enhancement:
SCSI Manufacturer Contact Information:
How can I contact:
Manufacturer Specific Questions:
Answers to the Questions:
ANSWER From: LSD, L.J.Sak@Kub. Edited by Gary
Field (scsifaq@bigfoot.com)
SCSI2 is the most popular version of the SCSI command specification and allows for scanners, hard disk drives, CD-ROM players, tapes [and many other devices]. SCSI-3 resolves many long time "gray areas" and adds much new functionality and performance improvements. It also adds new types of SCSI busses like fibre channel which uses a 4 pin copper connection or a pair of glass fibre optic cables instead of the familiar ribbon cable connection.
ANSWER From: Gary Field (scsifaq@bigfoot.com)
ANSWER From: Gary Field (scsifaq@bigfoot.com)
If you don't know what some of these things mean, read the rest of this document until you do. You'll get much more help if you appear to have made an effort to find the answer on your own before asking for help.
Asking a question like "My scanner doesn't work, how come?" may not even get you a response.
PLEASE DO NOT ASK "Which is better IDE or SCSI"?
Please spare us all the aggravation of the week long tirade that will
result from asking this seemingly innocent question!
ANSWER From: hennes@stack.urc.tue.nl (Hennes
Passmann)[Editor(GF)]
For WIDE SCSI there are 9 more signals; DB(p1), DB(8) ... DB(15)
ANSWER From: hennes@stack.urc.tue.nl (Hennes
Passmann)
Updated: April, 2003
1998
Ultra2: Bus
Speed of 40 MHz. LVD only.
ANSWER From: Gary Field (scsifaq@bigfoot.com)
In reality, there is no practical reason to do this. Any SASI device is so obsolete that is has no real value in a system being used in 1990 or later.
Answers From: Nick Kralevich <nickkral@cory.eecs.berkeley.edu>
edited by Gary Field (scsifaq@bigfoot.com)
The SCSI bus MUST run continuously from one device to another, like this:
DEVICE A --------- DEVICE B --------- DEVICE C -------- DEVICE D
Where device A, B, C, and D can either be internal or external devices.
The devices on the SCSI bus should have at least 4 to 6 inches of cable between devices. This is to satisfy the SCSI-2 requirement that "stubs" be placed at least .1 meters apart. Some devices that have a lot of internal wiring between the connector and the SCSI chip can look like a "stub" or bus discontinuity. The reason for all these requirements is that a SCSI bus is really 18 "transmission lines" in the wave theory sense. A pulse propagating along it will "reflect" from any part of the transmission line that is different from the rest of it. These reflections add and subtract in odd combinations and cause the original pulse to be distorted and corrupted. The terminators "absorb" the energy from the pulses and prevent reflections from the ends of the bus. They do this because they (hopefully) have the same impedance as the rest of the transmission line.
The SCSI bus must not have any "Y" shape cabling. For example, setting up a cable that looks like this is NOT allowed:
Termination must occur within 4 inches (.1 meter) of the ends of the SCSI bus.
The following ARE acceptable: +------------+----------+-----------+-----------+---------+ | | | | | | DEVICE A Unconnected Unconnected DEVICE B DEVICE C Adapter Terminated Terminated +------------+----------+-----------+-----------+---------+ | | | | | | DEVICE A Unconnected DEVICE B Unconnected Adapter DEVICE C Terminated Terminated +------------+----------+-----------+-----------+---------+ | | | | | | Adapter DEVICE A DEVICE B Unconnected Unconnected DEVICE C Terminated Terminated
+------------+----------+-----------+-----------+---------+ | | | | | | Adapter DEVICE A DEVICE B Unconnected Unconnected Termination Terminated
The following ARE NOT allowed: +------------+----------+-----------+-------------------+ | | | | | DEVICE A DEVICE B Adapter Unconnected Unconnected Dangling cable end Terminated Terminated
+------------+----------+-----------+-----------+ | | | | | Termination DEVICE A DEVICE B DEVICE C Adapter Termination in middle of bus Terminated
The placement of the SCSI adapter card can be on the end, at the beginning, or somewhere in the middle of the SCSI bus.
Quite frankly, placement of the controller card isn't special.
The adapter card is just another device on the SCSI bus.
As long as the rules above and in other sections of this FAQ are followed, there should be no problem placing the adapter card anywhere on the SCSI bus.
However, if you place the adapter card somewhere in the middle of the SCSI bus, you must be sure to disable termination on the adapter card. As noted previously, a SCSI device is only allowed to have termination if it's at the end of the bus. Only two terminators are allowed to terminate the SCSI bus, one at each end.
One last note: It doesn't make any difference where each SCSI ID is placed along the bus. It only matters that no two devices have the same ID. Don't forget that the adapter has an ID too. (Usually ID 7).
ANSWER From: Gary Field (scsifaq@bigfoot.com)
Updated: May, 1999
A SCSI bus is a transmission line. To prevent reflections from the ends of the bus, you need a device which makes the transmission line appear to be of infinite length. This is done by attaching resistors, which have the same resistance as the characteristic impedance of the transmission line, to the ends of the bus. Also, since SCSI line drivers are open-collector (which can only pull a signal low), a pull-up resistor is needed to pull the signal high when it's not asserted.
If the ends of the bus are not terminated, the signal pulses will reflect off these open ends and travel back along the bus in the other direction. The resultant adding and cancelling of signal amplitudes distorts and corrupts the SCSI signals.
There are two basic types of terminators, active and passive:
Recommendations and requirements:
In SCSI-2 when the fastest defined speed was 10 MHz, passive terminators
were allowed, but active terminators were recommended.
In SCSI-3, the "alternative X" terminology has been discarded, and
the SPI-2 standard only allows active termination for single-ended buses
regardless of speed.
My personal recommendation is not to buy any new passive terminators.
If you want to use up the old ones you have lying around, on older systems,
with short buses and no more than 4 devices, that don't have any devices
faster than 10 MHz, I can't argue with that, but ONLY BUY ACTIVE (or preferrably
LVD) terminators for any new systems. If you run into problems, switching
to an active terminator might well solve them.
Other people will tell you that only active terminators are ever acceptable
at any speed. I leave the choice up to the individual at Fast10 and below,
above that, active is absolutely the only acceptable choice.
I often hear the whine "It seems to be working, why should I bother
with the terminators?"
The following appropriate analogy was given to me by Kevin Kilzer:
"It only seems to work fine because you have not seen an error.
It's like having mice in your house. If you never see one,
you don't realize they are there."
Suddenly a problem will arise and you won't even realize it's associated
with the fact that you added a device to your SCSI bus two weeks ago. Termination
problems can manifest themselves in many ways. The best solution is to
avoid them by following the rules to the letter.
A final nit to pick:
As I was reminded in looking back at the standards, technically SCSI-2
did not sanction Fast10 on single ended buses. It was only spec'd for differential.
However, as was the case with WIDE SCSI using the 68 pin P cable, the industry
latched onto it and it later became standardized in SCSI-3 SPI.
ANSWER From: Roger J. Hamlett (Roger@ttelmah.demon.co.uk)
Updated: November, 1999
ANSWER From: Gary Field (scsifaq@bigfoot.com)
The ANSI SCSI spec's say that "stubs" on a SCSI bus must not be any more than .1 meters (4 in.) long. In SCSI-2 there are also guidelines that say you shouldn't place "stubs" any closer than .3 meters (12 in.) apart. Since each device attached acts as a "stub", you really shouldn't place connectors any closer than this. This gets to be more important as your bus performance goes up. i.e. with Fast20 it is very important, but with SCSI-1 it doesn't really matter much. Since Fast20 also limits your overall bus length to 1.5 meters (for single ended) this also means you shouldn't really connect more than 5 devices for best reliability.
Another minor enhancement involves altering the spacing of adjacent connectors to prevent reflection resonance.
e.g. place connectors at one end, then .3m, then .56m then .86m then 1.12m
Overall, the cable impedance and configuration (straight vs. twisted pair) are probably more significant factors than connector spacing. However, if there is room for the extra cable, I recommend spacing the connectors as described above for best reliability.
Excess cable length is also a bad thing, so basically all these factors must traded off against each other to build the best SCSI cable for a given situation.
ANSWER From: Gary Field (scsifaq@bigfoot.com)
The SCSI bus length limits are based on the speed of the fastest device attached to the bus.
Here's a table which shows the limits:
| Speed of FASTEST device | Max. Single-Ended bus length | Max. HV Diff. bus len. | Max. LVD bus length |
| 5 MHz (SCSI1 synch.) | 6 meters | 25 meters | 12 meters |
| 10 MHz (SCSI2 FAST) | 3 meters (not recommended in SCSI-2) | 25 meters | 12 meters |
| 20 MHz (Ultra or Fast20) | I recommend no more than 1.5 meters. The SCSI-3 SPI spec. gives a much more complicated reommendation. | 25 meters | 12 meters |
| 40 MHz (Ultra2 or Fast40) | Not recommended | 12 meters | 12 meters |
| 80 MHz (Ultra160) | Not recommended | Not recommended | 12 meters |
These limits assume the use of good quality cable, and the use of active terminators or LVD/SE terminators at each end of the bus.
Notice that I used the term MHz to specify speed since MB/sec. changes with the bus width.
Note: Bus width doesn't change the maximum allowable length. The bus width is independent of bus length or speed.
The above table assumes that you know the max. speed of your devices (usually by looking in the manuals). Some software (like Adaptec EZ-SCSI) provides a driver status monitor which will tell you what mode the devices are actually in. This is important, since any synchronous speed must be negotiated by either the device, or the adapter. The speed actually used will be the least common denominator between the two.
For example, if a Fast20 disk is attached to a "SCSI2" host adapter that only goes up to Fast10, the device will only run at 10 MHz.
In systems with high performance disks and external peripherals which
require long cables (i.e. external scanners, tapes or CDROM changers),
you may want to put the external devices on their own bus to avoid having
to slow down the fast disks. There are dual channel host adapters to make
this simpler (avoids using multiple IRQs etc).
The SCSI Trade Association also has a handy table.
ANSWER From: Gary Field (scsifaq@bigfoot.com)
(updated February 2001)
The main rule of SCSI IDs is that they all need to be unique on a per bus basis. Each device on a particular bus must be set to a different ID so that they can address each other without confusion. Some devices have a sticker on the drive which shows the ID pins, but if your does not, you'll need the data sheet for the device. The pins to jumper are obvious if you know how to count in binary, if not there is usually a table of jumper combinations on the data sheet for each ID setting.
There is a secondary consideration in setting IDs though; Higher ID
numbers have a higher priority on the bus.
The overall ID priority order on a WIDE bus is as follows (highest
to lowest): 7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9, 8.
There are at least two philosophies on how to use the device priorities
to best advantage:
Method 1:
Set the host adapter's ID to 7. The next lower IDs (6, 5, 4 ...) would
then be used for any time critical devices you may have such as streaming
tape drives or CD-RW drives. Your hard disks would be set to lower priority
IDs because they are generally the fastest devices on the bus and if given
too high a priority will hog all the bus bandwidth and "starve out" the
slower but time critical devices.
Method 2:
This philosophy maintains that devices that create the load should
be given low priorities and devices that relieve the load should be given
higher priorities. In this view, the host adapter creates the load (I/O
to be done), therefore, set the host adapter's ID to 0(or even 15 if no
narrow devices will be attached). The time critical devices (streaming
tape and CD-RW) would then be assigned highest priorities. Everything else
(including disks) would be assigned IDs in between. The placement of the
load creator at low priority pretty much prevents the "starvation" scenario.
To my knowledge no benchmarks have been published that show one method to be superior to the other. I would appreciate it if anyone would run some good tests to prove what the best method is or point to existing published results supporting one of these methods (or even another method).
Method 1 is apparently supported by Adaptec since they set all their
host adapters to ID 7 by default.
I personally doubt that it makes very much difference which method
you choose except on very heavily loaded systems where the drivers take
full advantage of tagged command queueing etc.
Special consideration for older host adapters:
Many older host adapters make the assumption that the boot disk will
be at ID 0. Most newer ones however, allow the user to specify which ID
to boot from.
See also 1
ANSWER From: Gary Field (scsifaq@bigfoot.com)
February 2001
ANSWER From: Gary Field (scsifaq@bigfoot.com)
Updated: Jan, 2002
Pros of IDE/ATA:
Some people point to the need to set IDs in SCSI as making it more
complicated, but it's really no more complicated than choosing master/slave
jumpers in IDE.
---------------
Now that I've said that, here's an article to show that there's more than one opinion on this subject:
From: Ed Schernau <mithrandir@ids.net>
Subject: FYI: EIDE and DMA/Scatter-Gather
The Western Digital Caviar EIDE drive that came in what is now the file server in our office came with a Win3.x 32 BDA driver which allowed the user to select DMA type (B or F) and to implement scatter-gather.
Also, the Intel Triton chipset implements 2 EIDE controllers, and I know that at least the 1 on the PCI bus supports bus-mastering, as well as DMA. However, PIO transfers can be faster, the infamous Mode 4 can in theory, do 16.6 MB/sec and I've heard of a Mode 5 which can do 22 MB/sec. Which [PIO] is only a benefit in single-tasking systems like DOS or Win3.x. Sounds like Intel is trying to make EIDE into SCSI, eh?
ANSWER From: Andrew Korn (korn@eik.bme.hu)
For home users this is a difficult question to answer in general. It totally depends on how you use your system, what operating systems are installed, and whether you will add more I/O devices in the future.
For server systems in a corporate environment the only sensible answer is to go with SCSI peripherals.
IDE has been improved a lot in the past few years, so in most cases it will be an acceptable choice for home users. You should consider the following
(we are mostly talking PC hardware from now on):
1. Your motherboard probably has an integrated EIDE controller capable of supporting up to four devices. (Older motherboards may not have a dual-channel IDE controller, in which case only two drives can be connected; even older motherboards may not be equipped with an IDE controller at all.) If not, an IDE controller for your system should cost less than $30, which is about half of what a decent SCSI host adapter (Symbios 53C810 based) would cost you. On the other hand, some high-end motherboards come with integrated SCSI host adapters.
2. EIDE is a single threaded architecture. This means that of the two drives connected to an IDE channel, one will always be idle while the other is executing a command. If you only want a hard disk and a CD-ROM drive, you can install the CD-ROM on the secondary IDE channel (the hard disk will probably be the primary 'master' drive); in this case, the aforementioned limitation does not affect you. Also, if you only plan on using single-tasking operating systems such as DOS, you needn't be concerned about this single-threadedness.
SCSI devices share the bus bandwidth efficiently by allowing one device to transfer data while another is seeking or rewinding its media. This will, however, only gain you performance if you use a proper multi-tasking operating system (such as Linux/UNIX [Editor(GF): or Windows NT/2000]).
3. By default, IDE devices use PIO (Programmed I/O) to communicate with the rest of the system. This has the drawback of consuming a lot of CPU time. However, most newer EIDE controllers support bus-mastering and most drives support DMA or even UDMA transfer modes. Using bus-master DMA decreases CPU consumption to almost zero. (It may not be easy to activate the DMA transfer mode under DOS, however.)
Early SCSI host adapters had much the same problem, but all newer ones support DMA transfers.
4. If you plan to use only two drives (one per IDE channel), IDE will probably be slightly faster and definitely less expensive than SCSI.
If you think you need more than two drives, plan to use a multi-tasking environment (such as Unix, OS/2, Netware or Windows 95/98/NT/2000), and think that performance is more important than cost, SCSI is the way to go.
Anything bigger than a small low-cost Linux-based server should probably use SCSI.
5. IDE tapes are not as cool as SCSI tapes. They tend to be slower, less reliable and less compatible with each other than SCSI tape drives. SCSI tapes are more expensive, however.
6. IDE is probably slightly easier to install. Termination is not an issue, and it will probably require no effort on your part to make the system aware of any new devices you add. In some increasingly rare cases this may not be true for SCSI. (You know what SCSI stands for? "System Can't See It." :))
Especially with older systems it may not be trivial (or, in rare cases, even possible) to make the computer boot from a SCSI drive.
7. It is problematic to add more than four IDE drives to a system. If you think you will need more than that, SCSI is probably the choice for you.
If your motherboard came with an integrated EIDE controller, however, there is no need to ignore that feature; you can have a mixed system with both IDE and SCSI devices. (Remember to buy SCSI where performance and parallelism is an issue; but there is no need to buy an expensive SCSI CD-ROM drive if an IDE drive would suit your needs.)
8. If you need high reliability, you want to buy a RAID capable SCSI host adapter. Be aware, however, that it is possible to emulate RAID from software; Linux can do RAID 0, 1, 4 and 5 with any mixture of SCSI and IDE disks. This software-based solution is probably less reliable and slower than a true RAID controller, but certainly also much less expensive. [Editor(GF): You can't boot from a software RAID set under Win2000 but you can under Linux].
[Editor(GF): ATA and IDE are basically the same thing, and the terms are used interchangably in this document.]
Here's a discussion that shows some of the advantages of SCSI in more detail:
from: Greg Smith (GREGS@lss-chq.mhs.compuserve.com)
Under DOS (and DOS/win3.1), there is very little useful work the host can do while waiting for a disk operation to complete. So handing off some work from a 66 MHz 486 to, say, an 8 MHz Z80 (on the controller) does result in a performance loss. Under EVERY other OS worth discussing (Unix, Netware, NT, OS/2, Win95/98 etc) the processor can go off and do something else while the access is in progress, so the work done by the other CPU can result in a performance increase. In such systems, due to virtual memory, a 64K byte 'contiguous' read requested by a process may be spread to 16 separate physical pages. A good SCSI controller, given a single request, can perform this 'scatter/gather' operation autonomously. ATA requires significant interrupt service overhead from the host to handle this.
Another big issue: ATA does not allow more than one I/O request to be outstanding on a single cable, even to different drives. SCSI allows multiple I/O requests to be outstanding, and they may be completed out of order. For instance, process 'A' needs to read a block. The request is sent to the drive, the disk head starts to move, and process 'A' blocks waiting for it. Then, process 'B' is allowed to run; it also reads a block from the disk. Process B's block may be sitting in a RAM cache on the SCSI controller, or on the drive itself. Or the block may be closer to the head than process A's block, or on a different drive on the same cable. SCSI allows process B's request to be completed ahead of process A's, which means that process B can be running sooner, so that the most expensive chip - the system CPU - tends to spend less time twiddling its thumbs. Under ATA, the process B request cannot even be sent to the drive until the process A request is complete. These SCSI capabilities are very valuable in a true multi-tasking environment, especialy important in a busy file server, and useless under DOS, which cannot take advantage of them.
I tend to hear from people, 'Well, I never use multitasking' because they never actively run two programs at once - all but one are 'just sitting there'. Consider what happens though, when you minimize a window which uncovers parts of four other application windows. Each of those applications is sent a message telling it to update part of its window; under win95, they will all run concurrently to perform the update. If they need to access disk (usually because of virtual memory) the smoothness of the update can depend a lot on the disk system's ability to respond to multiple independent read requests and finish them all as quickly as possible; SCSI is better at this.
So, yes, ATA can be faster under DOS; but SCSI provides advantages which are inaccessible to DOS. They will benefit Win95 however. The cost of intelligent, fast SCSI controllers and drives should decrease as people discover these advantages and start buying them.
I should add that many of SCSI's advantages are NOT available with some of the simpler SCSI controllers which were targeted only to the DOS market or part of cheap CDROM add-on kits.
Furthermore, SCSI allows far greater flexibility of interconnect. I concede that for the mass market, which likes to buy pre-configured machines, this is but a small advantage.
QUESTION:Why do SCSI disks cost so much more than IDE/ATA disks?
ANSWER From: Gary Field (scsifaq@bigfoot.com)
The increased cost of SCSI disks is primarily due to four factors:
ANSWER From: Gary Field (scsifaq@bigfoot.com)
The short answer is YES. There are a few issues to consider however.
The main issue is which device will be used for booting the system. Under MSDOS, The system BIOS determined this completely. A couple third party BIOSes (like MRBIOS) allowed the user to choose the boot source, but most conventional BIOSes just booted from the IDE if it was present. If no IDE was present then the standard option card BIOS scan would find the SCSI card's BIOS and use it to boot.
Under Windows 95 and Windows NT, there are more options. Since the motherboard BIOS is used to load the boot sector that will still happen according to the same rules as under MSDOS described above. After the boot sector is loaded, the O/S's device drivers take over and those can be unloaded or drive letters re-ordered via the O/S configuration tools.
Update: As of 1999, this issue has largeley been solved. Most BIOSes allow the user sufficient control to boot from whatever device they want to (either SCSI or IDE).
ANSWER From: Gary Field (scsifaq@bigfoot.com)
with input from Michael Burke and Cees de Groot and Sheldon E Smith.
Updated: Jan, 2001
Yes, two (or more) hosts can be on the same SCSI bus as other SCSI devices. As long as all the SCSI hardware requirements are met, multiple hosts can share the SCSI bus. With that said, let's look at what you're getting yourself into.
This discussion refers primarily to PCs. There are high end systems
that do allow full of sharing SCSI devices. Usually, this is to allow
fault tolerance. Two systems are connected to the same set of SCSI storage
devices and when one of them fails, the other takes control. AIX with HACMP,
Compaq Tru64 UNIX with TruClusters, and Compaq VMS clusters are examples
of systems that allow this. The combined group of systems with shared
storage is often referred to as a cluster. Open VMS and Tru64 V5.x and
newer also have a feature called the Ditributed Lock Manager which allows
multiple hosts to actually share the filesystems on shared disks locking
individual records as needed.
I am told Windows 2000 server now supports host fail-over for fault
tolerant support of shared disks/RAIDs.
Some basic things you need to watch out for:
For Disks:
It would not make sense for two hosts to go about treating shared disks
as if they each owned the device. Data would be destroyed pretty quickly.
Even if the user tries to only access the shared disk from one host at
a time, each host retains a cache of filesystem meta-data(directories etc)
and neither host can know what the other host is changing on the disk.
Therefore, unless one of the hosts restricts itself to read-only access,
the filesystem will get corrupted.
Another way of letting multiple hosts share a disk is to break up the
disk into partitions that are reserved for each host. Each host "owning"
its own file system. Some provision needs to be made to prevent either
host from using the wrong partition however. I'm not aware of a good way
to do this.
For CD-ROMs and scanners:
CD-ROM drives and scanners can be shared (for data access) pretty easily
because they are by definition READ-ONLY, but you can't be reading data
from one host and playing music on the same drive from another. With scanners,
discipline will be required to avoid attempting to access the scanner from
both hosts simultaneously.
For Tapes:
Sharing tape devices is straightforward unless you need to handle failing-over
from one host to another. If you want to do this the tape backup application
needs to be written to know how to determine the position on the tape where
writing was last successful and take up from there. If the RESERVE/RELEASE
mechanism is used to reserve the tape drive, a bus reset will need to be
used to break the reservation upon host fail-over. The reset will start
the tape drive rewinding, so the application will need to find where it
left off before it starts writing again, or start the backup over again.
For host to host communication:
Some people get the bright idea that it would be cool to transfer data
directly from one host to another via the SCSI bus. While this might be
cool indeed, you'll have your work cut out for you to get it to work! In
order to do this one of the host adapters needs to flip into "target mode".
In this mode the "target mode" host is made to appear like a disk or tape
to the other host and data can be written/read to/from it in the usual
manner. The snag is that software that does this is very rare and only
works on specific host adapters. See here for
more info on target mode and vendors that supply software.
Conclusions:
Before considering implementing a shared SCSI bus configuration, you
should examine your motives for wanting to do this. If you simply want
to transfer data between the systems, a network (10/100 base T) is a MUCH
simpler solution. A pair of ethernet cards costs about $50 and all the
software you need is built into both Win95/98/NT/ME/2000 or Linux.
If you need fault tolerance, maybe you really do need a shared bus,
but be prepared for lots of expense or years of painful software
development.
Table of Contents
QUESTION:What
is the problem with the Adaptec 1542C and external cables?
ANSWER From: Scot Stelter, Adaptec (Product
Manager for the AHA-1540)
Several articles lately have cited the importance of SCSI-2-compliant cables when cabling SCSI bus subsystems. Perhaps the most accurate and technically detailed one was published in Computer Technology Review in March '93 (Volume XIII, No. 3. PP. 6). In short, it explains the double-clocking mechanism that can occur due to cables whose impedance falls below the 90-Ohm SCSI-2 spec. Steep edge speeds on the REQ and ACK lines of the SCSI bus exacerbate the problem, but non-compliant cables are the root cause. Both LAN TIMES in the US (5/24/93, page 115) and CT Magazine in Germany (7/93, page 18) cite this cable problem.
In an extensive survey of cables available in the US and Europe, we found that more than half of the cables available have single-ended impedances in the 65 to 80 Ohm range -- below the 90 to 132 Ohms specified in the SCSI-2 spec. It seems that some (not all) cable vendors do not understand the specification, describing their cables as SCSI-2 compliant when they are not. A common misconception is that SCSI-2 means a high-density connector. In fact, there are several connector options. I have published a technical bulletin that summarizes the critical requirements (TB 001, April 1993). An artifact of its faster design left the AHA-1540C with faster edge-speeds than its predecessor, the AHA-1540B. As I have said, this can exacerbate the effect of bad cables. This explains why some users could get their AHA-1540B to work when an early AHA-1540C might not.
Essentially, the 1540B was more forgiving than the early 1540Cs. Good cables fixed the problem, but unfortunately for the user, good cables are hard to find.
After surveying the cable market and many of our customers, we decided that bad cables were going to be here for a while, and we had to make the 1540C as forgiving as the 1540B was. At the end of April '93 we made a change to the AHA-1540C that involved using a passive filter to reduce the slew rate of the ACK line, the signal that the host adapter drives during normal data transfers. Extensive testing with many intentionally illegal configurations confirms that we succeeded. Prior to release, we tested the AHA-1540C with over 200 peripherals, systems and demanding software programs with no failures. Then, a second team retested the AHA-1540C across a wild combination of temperatures, humidities and other stresses. This testing gives me confidence that the AHA-1540 line continues to serve as the gold standard for SCSI compatibility.
ANSWER From: fishman@panix.com (Harvey Fishman)
The AHA-1542A is obsolete and no longer supported by Adaptec. They stopped providing firmware upgrades at some level prior to the equivalence to the 3.10 level of the AHA-1542B firmware. I am not sure just where though. The present latest AHA-1542B firmware is version 3.20, and supports drives up to 8GB under MS-DOS.
ANSWER from: Terry Kennedy (terry@spcvxa.spc.edu)
The 1542C is an an updated model which replaces the 1542B. The 1542C features jumperless setup, having only 8 DIP switches. All other configuration options are set using the 1542C's built-in BIOS configuration utility. Configurable features not found on the 1542B are:
ANSWER from: Terry Kennedy (terry@spcvxa.spc.edu)
The 1542CF includes all of the 1542C features, and adds "Fast" SCSI operation, providing SCSI data rates of up to 10MB/sec (compared with an upper limit of 5MB/sec on the 1542C). This is unrelated to the host DMA rate. It also has a software configurable address for the floppy controller and a "self-healing" fuse for termination power.
ANSWER From: Gary Field (scsifaq@bigfoot.com)
You can get some older drivers and spec's from Adaptec's web site in the support section]
UPDATE: November 1999
Optical storage has good points going for it; Immunity to stray
magnetic fields; Potential for higher storage capacity per unit area; and
relatively low media cost.
Current optical storage solution offers two different types of storage
--rewritable and non-rewritable. The non-rewritable represents storage
method in which the data becomes permanent after being written onto the
disc. Rewritables, on the other hand, allows you to alter the data after
it has been written -- just like the magnetic storage devices. And for
rewritables, two different technologies are available -- magneto-optical
("MO") and phase-change ("PD").
Magneto-Optical
As the name implies, MO uses both magnetic and optical technology to store data on the disc. The disc itself is rare earth metal substrate. When data is to be written, the particular spot is first heated by the laser to the Curie point, and the magnetic field is generated while the spot cools. By varying the magnetic field angle, the substrate is polarized in a certain way that it will reflect back the laser beam differently depending on the magnetic field angle present when the particular spot was cooling down.
MO comes in many sizes and capacities. Consumers were first exposed to MO in Steve Jobs' NeXT computer in the mid-1980s. Although 5.25" had a slow start due to initial high cost, it has been evolving quite nicely.
The more popular ISO capacities for 5.25" MO are 4.8GB/5.2GB, 2.4GB/2.6GB, and 1.2GB/1.3GB. In 3.5" form, MO is available in 540MB/640MB, 230MB,and the 128MB. There are also some 12" MO, 14" MO, and other odd sizes in odd capacities -- particularly the hybrid 3.5" 1.3GB MO/PD drive. But they are limited to niche markets due to high cost and rarity.
Sony MiniDisc-Data is derived from the Mini-Disc (MD) audio format cartridge introduced earlier. MD-Data is to MD as CD-ROM is to digital audio compact disc (CD-DA). MD-Data (and digital audio MD) is based on the same magneto-optical technology, which partially explains the initial high-cost of the consumer MD audio recordable units. Fow now, MD-Data is the smallest of the MO family. With 2.5" form factor, it can store either 140MB or 650MB of uncompressed data.
Sony pushed the original MD-Data in the mid-'90s, but it did not catch on due to high cost (for the capacity offered) and Sony's decision to separate MD audio function from MD-Data. And for few years, MD format has lagged behind the capacity and speed of fellow MO breathens. In November 1999, Sony announced the MD-Data-2 format and has gotten the format up-to-date. It now has 650MB storage capacity with equal increase in transfer speed. The MD-Data-2 debuts with Sony's MPEG-2 camcorder in the Japanese market in December of 1999. The most important technical advancement MD-Data brought for MO in general is the one-pass recording. Prior to 5.25" 2.4GB/2.6GB MO and 3.5" 540MB/640MB MO, practically all MO used two passes to write data onto the disc -- one pass to erase the whole track, and a follow-up pass to write the updated data. MD's one pass recording, called light intensity modulation, direct over-write (LIM-DOW, ISO 14517) has been incorporated into several later-generation MO formats to speed up the writing speed.
Anyway, what's the limit of erase/write cycle can MO endure? Well, it doesn't look like anyone is really sure about it. Few years past, it is guessed to be around 1 million times with 30 years of archival stability. Today, Maxoptix says MO can sustain "greater than 1 trillion" cycles with greater than 50 years of archival storage life.
Today, the popular MO formats are 3.5" and 5.25" that follow the ISO standard. (Yes, there are others. But they're far and few in between...) The drives and medias are available from Fujitsu, IBM, Maxoptix, Pinnacle Micro, Pioneer Sony, Toshiba, and others.
Panasonic phase-change double-function (PD)
In around mid-'95, Panasonic released a proprietary optical storage format called phase-change double-function (PD) drive. The PD uses substrate that will reflect the light differently when heated to different temperatures (and then cooled). Write-once-read-multiple (WORM) medias were actually the first phase-change formats, but PD is the first *reversible* (that is, "re-writable") phase-change format. Panasonic PD stores 650MB per PD cartridge. Panasonic's own PD drive has also gone away with Sony's MD-Data, but the technology lives on in forms of CD-RW and DVD-RAM. The PD media is said to take approximately 1,000 erase/write cycles. After about 1,000 cycles, the substrate will be fatigued to the point where the two different states of the crystalline structure will become difficult to differentiate reliably.
WORM
Write-once-read-multiple (WORM) format is a *write once* format -- once you have written the data to the disc, the written data cannot be changed. Put it another way, the data recorded on the disc media is *permanent*.
WORM was the first popular format for optical storage, before being eclipsed by MO. WORM is still used by big companies and the government for archival purposes since it has the characteristic of not being able to be altered without damaging the media (good audit trail).
The new WORM formats being introduced are tending to be proprietary. There is rarely any interchangability between different vendor's drives and media. During the WORM to MO transition period, a curious format called continuous composite write-once (CCW) appeared. CCW cartridges function as WORM cartridges, writable using the installed base of WORM drives. But put it into MO drive, CCW cartridges becomes rewritable. Simply put, CCW is MO in WORM's clothing. Many of today's 5.25" MO drives still have the capability to read CCW cartridges. And practically all WORM cartridges sold today are CCW variety.
Sony-Philips Compact Disc (CD-R/CD-RW)...
WORM (in "MO" form) was once limited to niche market, but made one heck of a come-back with form of CD-R. CD-R is based on the Sony-Philips' proprietary CD-DA, commonly referred as "CD" (you know, those shiny disc things that America-On-Line sends you). CD-R offers standard capacity of 650MB of data per disc, and can be used to store data or record music (and be played in common CD players). But here, only the data-storage facet of the CD-R/CD-RW is discussed.
As far as data storage is concerned, the specifications are written in the "Orange Book." The Orange Book established three physical format for recordable CDs -- CD-MO, CD-R (previously known as "CD-WO"), and CD-RW (previously known as "CD-E").
CD-MO is a MO medium in CD format. As far as I know, this format only exists only on paper. The popular formats to come out of it are CD-R and CD-RW.
CD-R/CD-RW Incompatibility
Sony and Philips finally agreed on a standard for compact disc re-writable
(CD-RW), together with HP, Matsushita, etc. Long story short, the CD-RW
uses phase-change media -- same as Panasonic proprietary PD format. Not
only that, it also stores 650MB like PD. And also like the PD, the CD-RW
media cannot be read in existing CD-ROM drives! CD-ROM drives manufactured
in 1997 and after will read CD-RW discs though.
CD-R and CD-RW are known for their incompatibilities. There are combinations
of CD-R media, CD-R recorder, and CD-ROM player that simply wouldn't work.
CD-RW is worse -- virtually no audio CD players will play CD-RW disc. The
problem stems from the fact that reflectivity of the CD-R is less than
a factory-pressed CD-ROM. And CD-RW is worse in that respect than the CD-R.
As such, only the very recent CD-ROM player labled "Multi-Read" can read
the CD-RW discs.
DVD
Possibly the most soap-operatic of all data-storage formats. With convergence of computers and audio/video equipment, DVD was the most talked about format for years as several companies fighting for what "DVD" format should be.
Writable DVD formats:
For now, DVD-RAM is not made to be playable in DVD-ROM players that
are so popular for its good pictures. If you've looked at it, you'll notice
DVD-RAM is encased in a carriage case (a la MO-style) but "video" DVDs
aren't. Although I think it may be possible to take the DVD-RAM media out
of the case and stick it into computer DVD-ROM to read the recorded data.
What's the difference between DVD-RAM, DVD-RW, and DVD+RW? (March 2000)
The names differ depending on whose specification the DVD storage is
based on. If it's Matsushita (Panasonic), then it's DVD-RAM; if it's Sony/Philips,
then it's DVD+RW; or if it's Pioneer, then the name becomes DVD-RW. The
majority of current DVD storage devices follow Matsushita's DVD-RAM standard.
Pioneer currently has its DVD-RW in the form of a DVD video recorder in
Japan. Each has slightly different storage capacities. It's still unknown
whether they'll be truly compatible with each other. But all three specs
have been submitted and all are regarded as DVD re-writable "standards."
The Future?
Future optical storage will likely get bigger and bigger capacities, and faster and faster transfer rates.
Anyway, MO is here to stay, so are CD and the DVD family of formats.
As for DVD... The competitions should prove to be entertaining (not). DVD
is not much about technology but more about politics. But since so many
electronic and entertianment giants are backing the DVD, you probably won't
go wrong if you buy one. (Just hope the one you buy will not be orphaned
at the turn of the hat by DVD consortium.) Some form(s) of DVD recordable
will eventually standardized, but don't expect it to have more storage/speed
than what MO/PD/WORM formats offer.
Summary of optical disk formats
Format * |
Physical Size |
Capacity per disk |
Bytes per sector |
# of sides |
Capacity per side |
Standard |
MO 1p |
2.5" |
140MB |
2048/ 2336 |
Single |
140MB |
Sony MD-Data |
| MO 1p | 2.5" | 650MB | 2048/2336 | single | 650MB/720MB | Sony MD-Data-2 |
MO 2p |
3.5" |
128MB |
512 |
Single |
128MB |
ISO/IEC 10090, ECMA 154 |
MO 2p |
3.5" |
230MB |
512 |
Single |
230MB |
ISO/IEC 13963, ECMA 201 |
MO 1p |
3.5" |
540MB 640MB |
512 2048 |
Single Single |
540MB 640MB |
DIS(ISO/IEC) 15041 |
| MO/PD 1p | 3.5" | 1.3GB | 2048 | single | 1.3GB | ISO/IEC 14760 |
MO 2p |
5.25" |
600MB 650MB |
512 1024 |
Dual Dual |
296MB 322MB |
ISO/IEC 10089 ANSI X3.2121-1992 |
|
MO 1p |
5.25" | 654MB | ?? | single | 654MB | Pioneer |
MO 2p |
5.25" |
1GB 1GB |
512 1024 |
Dual Dual |
463MB 510MB |
ISO 13481 |
MO 2p |
5.25" |
1.2GB 1.3GB |
512 1024 |
Dual Dual |
595MB 650MB |
ISO/IEC 13549 and ECMA 184 |
MO 1p |
5.25" |
2.4GB 2.6GB |
512 1024 |
Dual Dual |
1.2GB 1.3GB |
DIS(ISO/IEC) 14517 |
MO 2p |
5.25" |
1.5GB |
4096 |
Dual |
750MB |
Panasonic |
|
MO 1p |
5.25" | 1.7GB | ?? | Dual | 654MB | Pioneer |
MO 1p |
5.25" |
4.6GB |
1024 |
Dual |
2.3GB |
Pinnacle Micro "Apex" |
| MO 2p | 5.25" | 4.1GB
4.8GB 5.2GB |
512
1024 2048 |
Dual | 2.1GB | ISO/IEC 15286 |
MO |
12" |
8GB |
?? |
Nikon |
||
MO |
12" |
3.2GB |
?? |
Sony |
||
MO |
14" |
6.8GB 10.2GB 14.8GB |
1024 1024 1024 |
Dual Dual Dual |
3.4GB 5.1GB 7.4GB |
Kodak System 2000 |
| WORM | 5.25" | 1.3GB | ?? | Dual | 650MB | ISO/IEC 11560 |
WORM |
5.25" |
2.6GB |
DIS(ISO/IEC) 15486 |
|||
WORM |
5.25" |
650MB |
Single |
650MB |
ISO/IEC 9171 Format A |
|
|
WORM |
5.25" | 654MB | ?? | single | 654MB | Pioneer |
WORM |
5.25" |
470MB 940MB 1.3GB |
Single Dual |
470MB 650MB |
Panasonic ISO/IEC 10091 |
|
| WORM | 5.25" | 1.4GB | ?? | Dual | 700MB | Panasonic |
|
WORM |
5.25" | 1.7GB | ?? | Dual | 654MB | Pioneer |
| WORM | 5.25" | 2.6GB | ?? | Dual | 1.3GB | ISO/IEC 15486 |
|
WORM |
5.25" | 5.2GB | ?? | Dual | 2.6GB | DIS (ISO/IEC) 18093 |
WORM |
12" |
15GB |
Sony |
|||
| WORM | 12" | 19GB | ?? | Dual | ?? | Pioneer LD-R |
|
WORM |
14" | 14.8GB
25GB |
DIS (ISO/IEC) 15898 | |||
PD 1p |
5.25" |
650MB |
4096 |
Single |
650MB |
Panasonic |
| CD-R | 3.5" | 130MB | 2048 | Single | 130MB | Orange Book |
CD-R |
5.25" |
650MB |
2048 |
Single |
650MB |
Orange Book |
CD-RW 1p |
5.25" |
650MB |
2048 | Single | 650MB |
Orange Book |
DVD-ROM |
5.25" |
4.7GB 9.4GB 17GB |
2048 2048 2048 |
Single 2layer dual |
4.7GB 9.4GB 9.4GB |
UDF ISO-13346 |
| DVD-R | 3.5" | 2.4GB | 2048 | dual | 1.2GB | 1.2GB, ECMA-279 |
|
DVD-R |
5.25" | 3.95GB
4.7GB |
2048 | Single | 3.95GB
4.7GB |
Pioneer |
|
DVD-R |
5.25" | 8GB | 2048 | dual | 4GB | ECMA-279 |
|
DVD-RAM 1p |
5.25" | 2.6GB
5.2GB |
2048 | Single
dual |
2.6GB | ECMA-272, ECMA-273 |
| DVD-RAM 1p | 5.25" | 4.7GB
9.4GB |
2048 | Single
dual |
4.7GB
9.4GB |
UDF ISO-13346 |
| DVD-RW 1p | 5.25" | 3GB
6GB |
ECMA-274 |
*technology: 1p -- one-pass write 2p -- two-pass writeStandards for storage are set by many organizations. International Organization for Standardization (ISO http://www.iso.org/), European Computer Manufacturers Association (ECMA), Deutsche Institut fur Normung (DIN), Japanese Industrial Standards Committee (JISC), and American National Standards Institute (ANSI) set the main optical disc storage standards. The ISO standards take precedence over all other standards.
In the above table, the heading defines one standard -- e.g. 5.25" MO 1.2GB/1.3GB has both ISO 13549 and ECMA 184 listed for it. IT IS NOT THAT 1.2GB FOLLOWS ISO 13549 AND 1.3GB FOLLOWS ECMA 184.
Of CD standards...
Funny as it seems, CD is actually considered as a proprietary format made by Sony and Phillips. The physical format for derivatives like CD-ROM and CD-R are "written in mutual agreement" in form of Red Book, Yellow Book, Orange Book, etc.
Of bytes/sector and usability...
As many of you might notice (especially on 5.25" MOs), there are different sized sectors. Many O/Ses assume one sector to contain 512 bytes. If you buy any of the media that use different than 512 byte/sector, you will need a software driver of some sort to use the media.
In optical media, the sectors are "hard sectored" at factory -- in other words, you cannot change the number of sectors by reformatting (low-level formatting) them. Take the 5.25" 1.2GB/1.3GB MO for example again. The 1.3GB media is sectored at 1024 bytes per sector. So the 1.3GB media has total of 637,041 sectors (per side) on it. If you do not use a software driver and your operating system does not properly recognize it, the 1.3GB media will become a 650MB cartridge (~325MB per side)!!
The safest bet is to use the 512 bytes/sector media. That should make the drive and media usable on most operating systems.
Thanks to John Lohmeyer of LSI Logic (formerly Symbios Logic, AT&T GIS, NCR Microelectronics), a number of SCSI related files are freely available.
This is the place to find more information about I/O Interfaces, especially
SCSI, SCSI-2, and SCSI-3 including SPI, Fast-20 (Ultra
SCSI), Fast-40 (Ultra2 SCSI), Low Voltage Differential (LVD), SPI-3
(Ultra3 SCSI or Ultra160), SPI-4 (Ultra320), CAM, and much more. There
are also pointers here to other web sites on Fibre Channel, ATA (IDE),
and ATAPI.
The information is accessible from:
WWW: http://www.t10.org
SASI Spec. - (.PDF format): ftp://ftp.t10.org/t10/drafts/sasi/sasir0C.pdf
SCSI-1 draft standard - (Plain text, no figures, Dec. 1985): ftp://ftp.t10.org/t10/drafts/s1/s1-r17b.txt OR here
SCSI-2 draft standard (converted to HTML) - http://www.danbbs.dk/~dino/SCSI/SCSI2.html
[Editor(GF): you might try: http://playground.sun.com/pub/SCA/SCAR3-2.txt]
From: Gary Watson (trimm@netcom.com)
Small Form Factor (SFF) Committee documents (like the SCA spec's) are available by FaxAccess at:
(408) 741-1600 You will be asked to order documents by number.
For example: to get information on the Single Connector Attach spec.
The SCA-1 spec. is document #8015
The SCA-2 spec. is document #8046 (8451?)
document #8000 is an index to the other documents.
SCA-2 pinout data can also be found in the SCSI3 SPI-4 document referred
to as "Alternative 4".
This FaxAccess service is available to all, but please keep in mind that unless you have engineering-level understanding of peripheral interfaces, you _will_not_ be able to understand any of it and you are wasting your own time and the bandwidth of these resources. If you are trying to learn more about SCSI, you are better off reading the magazine articles and books listed elsewhere in this FAQ.
The SCSI, SFF, SSA, and Fibre Channel reflectors:
A list of these is available on the T10 site.
"The SCSI, SFF, SSA, and Fibre Channel reflectors are for review and commentary on the respective specifications, not for asking questions about the interfaces (unless related to a specific ambiguity in a specification) nor for recruiting nor for technical support nor any purpose other than what is stated. The reflectors _are_ available for public review and commentary as required by ANSI and ISO."
Any spec on the reflectors or on the BBS or on the ftp sites are **proposed**
or **preliminary** and are often subject to major substantive changes during
the committee process. Actual, released, final specs are *only* available
from Global Engineering Documents.
For Fibre Channel Info:
For Firewire (IEEE-1394) Info:
ANSWER #1 From: kev@hpcpbla.bri.hp.com (Kevin Jones)
and jmatrow@donald.WichitaKS.NCR.COM (John
Matrow)
The SCSI specification: Available from:
ANSI
11 West 42nd St. - 13th floor
New York, NY 10036
Sales Dept. (212) 642-4900
OR
Global Engineering Documents
15 Inverness Way East
Englewood Co 80112-5704
(800) 854-7179 or (303) 792-2181
Int'l Sales Fax: (303) 397-2740
SCSI-1: X3.131-1986
SCSI-2: X3.131-199x
SCSI-3 X3T9.2/91-010R4 Working Draft
[Editor(GF):] The official ANSI standards are NOT available free of charge from any source. Only draft versions are freely distributable.
ANSWER From: Gary Field (scsifaq@bigfoot.com)
Updated: June, 2000
Published by No Starch Press, San Francisco, CA
ISBN # 1-886411-10-7 , List Price $49.95.
A very complete reference and tutorial on almost all aspects of SCSI,
including all the latest advances like Ultra2WIDE/LVD, and all the previous
standard SCSI features. It addresses everything you need to know to install
and debug SCSI I/O on a PC running Windows 95/98/NT and information
on Linux as well. Also includes a CD-ROM with useful SCSI utilities and
information.
The technical editor was none other than John Lohmeyer (chairman of
the ANSI SCSI committee since the beginning of SCSI), so you know the facts
are straight!
A complete description (as well as a link to purchase the book online at a significant discount) is available at My own web site
(408)867-6642, FAX (408)867-2115
"Programmer's Guide to SCSI" with CDROM - by Brian Sawert.
Published by Addison Wesley, Reading, MA. SRP $39.95
ISBN # 0-201-18538-5
Includes a chapter on UNIX SCSI subsystems written by Gary Field.
'The SCSI Bus and IDE Interface' 2nd edition by Friedhelm Scmidt,
Addison-Wesley Publishing, $34.95 (I think). It includes a diskette with examples of source code to handle SCSI and IDE devices from a low-level programmer's perspective, and it has very detailed technical descriptions of both subsystems.
Not a book for beginners, but I heartily recommend it for anyone who's
serious about learning the technical ropes.
There was a two part article in Byte Magazine. The first part was in Feb 1990 issue, p. 267-274 and the second was in Mar 1990 issue, p. 291-298.
Another two part article appeared in Byte in May 1986 and June 1986.
ANSWER FROM: Gary Field (scsifaq@bigfoot.com)
ANSWER: ekrieger@quasar.xs4all.nl (Eric Krieger)
(Updated Sep. 30, 1994)
Drive and Controller Guide, Version 4.3
THEREF(tm) is a comprehensive Directory of Hard Drives, Floppy Drives, Optical Drives, and Drive Controllers & Host Adapters. It is designed to help the novice and pro alike with integration problems and system setups.
Information is provided in two handy formats; Portrait mode, for those who prefer a normal book-binding type print format, and(or) do not have a printer with Landscape capability, and Landscape mode, for those who pre-fer a computer-printout type format.
For printing, a Laserjet is preferred, but not necessary, and setup info is provided. For viewing, LIST(tm) by Vernon Buerg, will provide an excellent result, and allow text searches for finding specific models.
By F. Robert Falbo
Due many reports about the unavailablity of this file/archive I made sure that the file does exist at the following site:
You should find the archive at:
/pub/doc/hardware/harddisks/theref43.tar.gz
/pub/doc/hardware/harddisks/theref43.readme
(In that directory-path there is also a sub-directory Seagate, where you also can find info/files about Seagate-drives).
Before you actually get this file, be sure to get/read the file /README.FILETYPES since it explains the used file-extension and which (de-)archiver should be used (and where to find/get them!).
Note: In the archive there are files containing Extended ASCII or ANSI characters (mostly used with IBM- and compatible PC's), so it may be a bit unreadable when reading it on non-PC systems, or without using a proper Characterset/Font!
TheRef is also available via WWW from: TheRef
ANSWER From: Rodney Brown (RBrown@cocam.com.au)
Update From: Martin C Mueller (mcm@mathematik.uni-kl.de
)
HP SCSI Storage Device Support Pages
http://www.hp.com/isgsupport/index.html