Scsi-know-how

Aus Atari Wiki-NEU
Zur Navigation springenZur Suche springen

SCSI

Eigentlich haben Sie schon immer mit SCSI-Geräten zu tun, aber so richtig viel wissen sie nicht darüber? Kein Problem, SCSI ist die einfachste Sache der Welt, wenn man einmal verstanden hat, worum es geht. Wir wollen uns nun mal die wichtigsten Dinge des SCSI-Bus ansehen, die für Anwender interessant sind, und etwas weitergehend das Verständnis für das Bus-System wecken. Aber vor allem sollte man danach wirklich die größten Probleme mit seinen SCSI-Geräten selbst in den Griff bekommen.

Geschichte

Der SCSI-Bus bzw. die Definition und Funktionsbeschreibung des SCSI-Bus basiert auf dem SASI-Bus, der von Shugart entworfen wurde. Damals stand SASI für 'Shugart Associated System Interface'. Im Prinzip war SASI sehr nah am heutigen SCSI, nur eben war es damals noch eine Inhouselösung bei Shugart. Wie bei so vielen Dingen wurde aus einem Inhousestandard eine gemeinsame Lösung für mehr Hersteller, was ja nicht immer etwas schlimmes ist (ja, ich denke da an eine ganz bestimmte Firma).

Nach ein wenig Normerei kam also die SCSI-Norm dabei heraus. Diese kümmerte sich zunächst nur um das allernötigste, nämlich die Technik des Busses, also die elektrischen Timings, die Antwortzeiten und ähnliches, eben die Beschreibung der Hardware, die SCSI ausmacht, und die allernötigsten Kommandos, die man so braucht, um überhaupt mal auf einem SCSI-Bus etwas anstellen zu können.

Diese Teilung sollte man übrigens immer im Auge behalten: die Normung der Hardware und die Normung der Kommandos, also der eigentlichen 'Sprache' auf dem Bus. Es stellte sich relativ bald heraus, dass zwar die Hardware gut und sehr weitsichtig genormt worden war, aber die Kommandos eben nicht. Die Kommandos unterteilen sich nämlich in sogenannte 'Mandatory Commands', 'Optional Commands' und 'Vendor Unique Commands'.

Die 'mandatories' sind Kommandos, die ein Gerät verstehen muss, um der Norm zu genügen, die optinalen Kommandos darf das Gerät unterstützen, muss es aber nicht. Wenn sie unterstützt werden, müssen sie sich aber auch an die Norm halten, wie das Kommando zu verwenden ist. Um den Herstellern Freiraum für eigene Möglichkeiten zu geben, gibt es dann eben noch die 'vendor unique' Kommandos, also 'dem Hersteller freigestellte' Kommandos, mit denen die Hersteller machen können, was sie wollen. Übrigens ist damit auch klar, dass man bei der Verwendung dieser Herstellerkommandos vorher unbedingt kontrollieren muss, ob es sich überhaupt um ein Gerät handelt, das diese Befehle wirklich kennt. Sonst könnte es passieren, dass zum Beispiel ein Befehl für ein ZIP-Laufwerk, um das Passwort des Mediums zu setzen, bei einem CD-ROM zu einem löschen der Firmware führt (bei einigen Laufwerken kann man die Firmware nämlich per SCSI-Bus ersetzen).

Kurz nach der Verabschiedung der SCSI-Norm begann daher der Normungsprozess der folgenden Norm, die als SCSI-2 bezeichnet wird, was dazu führt, dass die erste Norm heute eben als SCSI-1 bezeichnet wird. Vorab entstand dabei auch schon der CCS, der 'Command Command Set', also eine über die Norm hinausgehende Definition der Hersteller, bestimmte Kommandos gemeinsam identisch zu implementieren. Der CCS ist im Prinzip heute komplett Bestandteil von SCSI-2.

Die Unterschiede von SCSI-1 zu SCSI-2 sind dabei auch in drei Teile aufzutrennen:

  1. weitere Hardware-Definitionen
  2. erweiterte Protokoll-Definitionen
  3. weitergehende Kommando-Definitionen

Es handelt sich dabei immer um Erweiterungen, die nicht wirklich der vorhergehenden Norm widersprechen. Bei der Hardware sind ein paar zusätzliche Möglichkeiten aufgetreten, wie zum Beispiel ein schnelleres Timing der Datenübertragung, um schnellere Transfers zu erreichen, oder Busse mit größerer Breite als 16 oder 32 Bit, statt nur 8 Bit auf dem Bus.

Das Protokoll ist um ein wenig Etikette erweitert worden, die während der Zugriffe gepflegt werden soll, wie zum Beispiel, dass immer arbitriert werden soll, und nicht nur, wenn man möchte. Genauso ist vorgesehen, dass ein Initiator sich bei der Selektion identifiziert und ähnliche Kleinigkeiten, die aber normalerweise bei einer SCSI-1 Umgebung nicht weiter stören. Wesentlich ist jedoch die Normung der Kommandos und der Gerätedefinitionen. Die Beschreibung der Kommandos und der Parameter für die verschiedenen Geräte nimmt dabei auch einen erheblichen Platz der Norm ein.

Inzwischen ist die SCSI-3 Norm in vollem Gange und wie bei der SCSI-2 gegenüber der SCSI-1 geht es um Erweiterungen, unter denen alte Geräte von ihrer Hardware her nach wie vor laufen, sie benötigen höchstens eine neue Firmware, um voll der SCSI-2 zu entsprechen. Übrigens spricht man bei SCSI nicht von Ess-Zeh-Ess-Iih, sondern von Skasih [ska:zi:], damit es einfacher auszusprechen ist. Das hat nichts damit zu tun, dass man sich wichtig anhören will, es ist wirklich sinnvoll so, wie man ganz schnell merkt, wenn man es so ausspricht.

Geräte

Gegenüber so stumpfen und einfachen Bussen wie z.B. dem IDE-Bus (naja, eigentlich ist das gar kein Bus sondern nur ein Kabel) hat der SCSI-Bus einige Möglichkeiten mehr, wesentlich für den Anwender ist dabei zunächst die Tatsache, dass mehr als nur ein oder zwei Geräte angeschlossen werden können.

Bei SCSI sind das nun 8, 16 oder 32 Geräte insgesamt, bzw. aus der Sicht des Anwenders jeweils eines weniger. Woran liegt das nun? Eigentlich könnte man doch beliebig viele Geräte ansprechen, indem man einfach eine Gerätenummer übergibt. Dem ist jedoch nicht so, weil sonst einige der Features von SCSI nicht möglich wären. Die Anzahl der möglichen Geräte ist dabei gleich der Bus-Breite des SCSI-Bus, also 8 Geräte an einem normalen SCSI-Bus, 16 Geräte an Wide-SCSI mit 16 Bit Breite und 32 Geräte an Wide-SCSI mit 32 Bit Busbreite. Dies liegt daran, dass bei der Selektion und der Arbitrierung immer die Datenleitung gesetzt wird, die der Gerätenummer entspricht, entweder die eigene oder eben die des Gerätes, das man ansprechen will.

LUN

Was ist denn nun eine LUN schon wieder? LUN steht nicht für den Mond, sondern für 'Logical Unit Number', also für ein logisches Gerät. Ein logisches Gerät muss nicht tatsächlich existent sein, wenn es das auch oft ist. Ein SCSI-Gerät kann also solche 'Untergeräte' haben. Damit können innerhalb eines SCSI-Gerätes mehrere 'Teile' angesprochen werden. Die Nummer, die zur Ansprache dieses Untergerätes dient, ist die eben diese LUN (logical unit number)

Beispiele dafür sind:

  • mehrere physikalische Laufwerke auf einer SCSI-Id (zum Beispiel eine Megafile 30 mit 2 Laufwerken)
  • mehrere Medien in einem Laufwerk, wie bei CD-Wechslern. Bei den gebräuchlichen Wechslern stellt jedes CD eine 'Untergerät' dar, als wären es eben mehrere CD-Laufwerke.
  • logische Trennung verschiedener Laufwerkseigenschaften, z.B. Phase-Change-Laufwerke, die auf einer LUN das CD-ROM sind, auf der anderen die Festplatte

Besonders die logische Trennung verschiedener Funktionalitäten ist dabei sehr interessant, wenn es auch etwas fraglich erscheint, ob sich zwei LUNs innerhalb eines Gerätes als unterschiedliche Gerätetypen ausweisen sollten.

Terminierung

Das große Zauberwort für den Endanwender ist die Terminierung des SCSI-Busses. Diese Terminatoren sind Abschlußwiderstände, die den SCSI-Bus sauber beenden. Elektrische Signale ergeben am Ende eines Kabels ein Echo, genauso wie ein Schallsignal an einer Wand ein Echo ergibt. Dieses Echo muß gedämpft werden, um die Signalqualität auf dem Bus zu erhalten. Dazu werden nun eben die Terminatoren am Busende verwendet, die das Echo bedämpfen. Damit ist auch klar, dass die Terminatoren immer am Ende des Kabels sein müssen, egal wo welches Gerät angeschlossen ist. Genauso würden Sie in einem Tonstudio ja auch die Wände bedämmen und nicht die Dämmittel mitten im Raum aufstellen.

Für die Terminatoren ist aber noch eines wichtig: sie müssen mit Energie versorgt werden, sonst können sie nicht arbeiten. Werfen sie dabei nicht 'passive' und 'aktive' Terminatoren durcheinander, die benötigen beide Energie, sie arbeiten nur mit unterschiedlichen Techniken. Um nun die Terminatoren zu versorgen, gibt es eine Leitung auf dem SCSI-Bus, namens 'Termpower'. Auf dieser Leitung wird eben die Spannung für den Terminator geliefert. Die Spannung darf von jedem Gerät am Bus geliefert werden, aber Initiatioren, also die Geräte, die von sich aus Aktionen auf dem Bus auslösen, sind dazu verpflichtet, Termpower zu liefern. Damit ist sichergestellt, dass mindestens einer die Spannung versorgt, wenn nur einer anwesend ist, der den Bus benutzen möchte.

Eine besonders nette Falle liegt für Ataribesitzer darin, daß sowohl der Falcon als auch der TT nicht korrekt mit Termpower arbeiten. Der TT liefert an seinem externen SCSI-Port gar keine Termpower, was dazu führt, daß bei externen Geräten mindestens ein externes Gerät eingeschaltet sein und Termpower versorgen muß. Sollte es bei ihnen trotzdem funktionieren, wenn sie alle externen Geräte ausgeschaltet haben, so gibt es dafür nur zwei Möglichkeiten: purer Zufall oder sie besitzen nachgerüstete Termpower. Vernünftige Techniker rüsten nämlich jeden TT, den sie einmal offen vor sich haben, sofort mit Termpower aus, damit dieses Problem beseitigt ist.

Der Falcon legt dagegen eine andere Falle, die aber im allgemeinen für den Anwender nicht so gravierend ist. Der Falcon versorgt zwar Termpower, aber seine Terminatoren sind nicht mit Termpower vom SCSI-Bus verbunden. Ist also der Falcon ausgeschaltet, bekommen die Terminatoren keine Versorgung und funktionieren auch nicht. Auch das kann man nachrüsten, aber es ist wohl eher selten, da die Probleme auch nicht so relevant sind, denn wer hat schon einen Falcon zusammen mit einem anderen Rechner gemeinsam an einem SCSI-Bus.

1-2-3, Cola für Rußland

Immer wieder taucht die Frage auf, ob nun ein SCSI-1 Gerät mit einem SCSI-2 Gerät oder gar mit einem SCSI-3-Gerät kombiniert werden darf. Grundsätzlich gibt es dafür eine ganz einfache Antwort: ja. Solange die Schnittstelle die gleiche ist, ist das überhaupt kein Problem. Unterschiedliche Schnittstellen kann man logischerweise nicht kombinieren, denn z.B. an einer seriellen SCSI-Schnittstelle kann kein paralleles Gerät angeschlossen werden. Handelt es sich aber um den gleichen Schnittstellentyp mit dem gleichen Protokoll, so gibt es auch keinerlei Probleme beim Mischen der Geräte. Selbst 8, 16 und 32 Bit-Geräte können ohne jegliche Probleme miteinander gemischt werden, denn der Anfang der Kommunikation erfolgt immer mit 8 Bit-Breite. Erst nach der Übertragung des Kommandos machen die Geräte untereinander aus, ob sie gerne einen weiten Transfer machen wollen, oder ob sie die Daten synchron oder `Fast' transportieren wollen. Lediglich ein Kabeladapter ist also nötig, um die verschieden breiten Geräte an einem Bus zu mischen.

Viel gehörtes Gerücht ist dann auch, dass ein 8 Bit-Gerät an einem Wide-SCSI-Bus alle anderen zu 8 Bit-Transfers zwingt, genauso wie angeblich ein nicht-fast-Gerät alle anderen zu nicht-fast Zugriffen erzwingt. Lassen Sie sich da aber gar nichts weismachen, es stimmt schlicht und einfach nicht. Solche Dinge sind bei IDE völlig normal ('welchen PIO-mode darf den Platte xyz? Ja die darf 4, aber nur wenn sie nicht mit einer Platte von zzx zusammen am Bus ist, die kann zwar auch 4, aber zusammen können sie nur 3'), aber SCSI kennt sowas einfach nicht. Also immer wenn Sie ein Flachbandkabel mit einem 50-poligen oder 68-poligen Stecker vor sich haben: kein Problem, einfach dran stecken.

Kommunikation

Der interessanteste Teil bei SCSI ist die eigentliche Kommunikation. Abgesehen von der schnöden Tätigkeit, Daten zu transportieren (vom Rechner zur Festplatte oder auch vom Scanner zum Rechner oder wohin auch immer), kann SCSI einiges nebenbei, was dieser schnöden Tätigkeit zu erheblichen Leistungsgewinnen verhelfen kann.

Im Prinzip teilt sich die ganze Kommunikation in zwei Teile auf, die Selektion des Gerätes, mit dem man sprechen will, und dann eben die Transferphasen, in denen Daten und Informationen ausgetauscht werden.

Interessant ist dabei auch eine Sache, die dem Anwender im allgemeinen unbekannt ist:

Nachdem der Initiator, also der Auslöser der Kommunikation, den Kontakt zum Target, also zum Ziel seiner Kommunikation, hergestellt hat, übernimmt nämlich das Target die Macht über den Ablauf. Was während der folgenden Phasen wann stattfindet, sagt nur das Target, der Initiator hat da mitzuziehen. Leider scheint das bei den Autoren von SCSI-Software reichlich unbekannt zu sein, hat doch lediglich Claus Brod in CBHD dies so gemacht. In dem Treiber für die ATW von Atari war es ebenfalls so, aber dieser schöne Rechner hat ja nie so richtig die Öffentlichkeit erblickt.

Ansonsten teilt sich die Kommunikation eigentlich in zwei wesentliche Teile auf: die Herstellung des Kontaktes zum Target, und danach der Austausch der Daten zwischen Initiator uns Target.

Arbitrierung, Schiedsrichter für den SCSI-Bus

Auf dem SCSI-Bus können mehrere Initiatoren existieren, die wechselseitig den Bus benutzen können. Um zu entscheiden, wer gerade den Bus benutzen darf, wird die Arbitrierung, also eine 'Schiedsrichterentscheidung' verwendet. Dabei wird zu einem Moment, zu dem der Bus frei ist (erkennbar an der Busy-Leitung des Busses) eine Arbitrierung begonnen. Dabei setzen alle Geräte, die den Bus belegen wollen, die Datenleitung, die ihrer eigenen SCSI-Id entspricht. Dadurch können alle Geräte gleichzeitig sehen, wer sonst noch den Bus belegen möchte. Gewinner des Busses ist das Gerät mit der höchsten SCSI-Id, wobei zu beachten ist, daß die Geräte 0 bis 7 eine höhere Priorität besitzen als die Geräte 8-15. Dies ist zwingend darin begründet, daß die unteren Geräte die oberen Geräte nicht `sehen' können, wenn sie die Kontrolle durchführen, ob ein höher priorisiertes Gerät den Bus benutzen möchte.

Selektion

Nachdem man in der Arbitrierung den Bus gewonnen hat, kann man das Gerät selektieren, das man ansprechen möchte. Dabei wird neben der Select-Leitung, die ein Auswählen eines Gerätes anzeigt, die Datenleitung gesetzt, die der Id des anzusprechenden Gerätes entspricht, sowie das eigene Bit.

Das Setzen des eigenen Bits ist dabei seit der SCSI-2 Pflicht, um dem angesprochenen Gerät mitzuteilen, von wem es angesprochen wird. Dies hat einen wichtigen Grund: man kann ein Gerät für sich Reservieren, damit andere Initiatoren nicht dieses Gerät benutzen können. Wenn ein Gerät nun für die Benutzung eines bestimmten Initiators reserviert ist, muß es natürlich kontrollieren, ob die Selektion von diesem Initiator ausgeht. Diese Funktion nennt man `Initiator Identification' und die ist eben bei einigen SCSI-Geräten Pflicht. Dies hat aber ganz sicher nichts mit der Arbitrierung zu tun, die bereits vorher stattgefunden hat.

Das Gerät anwortet auf die Selektion, indem es die Busy-Leitung setzt, die dann bis zum Ende der gesamten Kommunikation gesetzt bleibt und anzeigt, daß der Bus belegt ist und im Moment kein anderer daran darf.

Fehlersuche

Es kommt natürlich immer wieder mal vor, daß ein SCSI-System nicht zum Laufen zu bekommen ist.

Man kann dann zunächst einmal eine ganze Menge an Standard-Kontrollen durchführen, mit denen man bereits die meisten Probleme erlegen kann.

Kontrolle der Terminatoren Auf dem SCSI-Bus muß grundsätzlich das Ende des Busses durch Terminatoren abgeschlossen werden. Dabei handelt es sich um Widerstände, die an den Kabelenden Reflektionen unterdrücken und die SCSI-Signale auf einen definierten Pegel bringen.

Ein Terminator ist etwa das gleiche, wie eine schallschluckende Oberfläche in einem Raum. Wenn man eine harte, glatte Wand hat, so gibt es Echos in dem Raum, bringt man jedoch eine weiche Oberfläche an der Wand an (zB Schaumstoff), so gibt es keine Echos mehr.

Von diesen Terminatoren dürfen immer nur zwei Stück angebracht sein: an den Enden des Kabels. Bei einem Terminator handelt es sich um Widerstandarrays, die meistens auf dem Gerät oder als externer Stecker angebracht werden. Auf einem Gerät besteht ein Terminator normalerweise aus zwei oder drei schmalen, roten, schwarzen oder gelben Steckerchen die bei dem SCSI-Anschluß des Gerätes in die Platine eingesteckt sind.

Eine andere Variante sind aktive Terminatoren. Diese können im allgemeinen durch einen Jumper auf der Festplatte aktiviert werden (zB Quantum LPS 540S : Jumper TE (Termination Enable))

Beachten Sie, daß die Terminatoren an den Enden des Kabels sein müssen, dies hat nichts damit zu tun, welche Gerätenummer das Gerät hat, an dem die Terminatoren sitzen.

Es ist immer zu beachten, daß sich die Terminatoren an Ende des KABELS befinden müssen. Befindet sich am Ende des Kabels ein Gerät, so muß das Gerät terminiert werden, handelt es sich um ein offenes Kabelende, so muß das Kabel terminiert werden.

Ein paar Beispiele:

Atari TT:

  • Einen Satz Terminatoren auf der internen Festplatte
  • Auf dem Mainboard des TT keine Terminatoren (drei Stück neben dem internen SCSI-Stecker
  • Von den externen Geräten das letzte mit Terminatoren versehen.
  • Sollten Sie keine interne Festplatte im TT haben, so sollten Sie das interne SCSI-Kabel entfernen und die Terminatoren auf dem Mainboard lassen.

Atari Falcon:

  • für den Falcon gilt das gleiche, wie für den TT ohne interne Platte, der SCSI-Port des Falcon ist intern terminiert, das letzte, externe Gerät muß terminiert sein

Geräte an DMA-Adaptern am ACSI-Port:

  • Im allgemeinen besitzen die Hostadapter eine Terminierung. Damit sollte der Hostadapter am einen Ende des Kabels angeschlossen werden, und am letzten angeschlossenen Gerät ein Terminator.

Einige Hostadapter haben keine Terminatoren, daher sollten sie irgendwo in der Mitte des Kabels liegen, und die Geräte an den Enden sollten twerminiert sein. Der GE-V ist ein solcher Adapter.

Kontrolle der Terminatorversorgung

Die Terminatoren müssen mit Strom versorgt werden, damit sie korrekt funktionieren. Dazu wird auf einer Leitung des SCSI-Busses eine Spannung von knapp 5V geliefert (5V abzüglich einer Diodenspannung). Auf einem SCSI-Bus muß daher unbedingt mindestenes ein Gerät eingeschaltet sein, und TERMPOWER liefern. Bei einigen Geräten kann per Jumper eingestellt werden, ob TERMPOWER geliefert werden soll.

Zur Kontrolle können Sie einfach die Spannung zwischen Pin 26 und Pin 1 am SCSI-Bus messen. Dort sollten knapp 5V anliegen.

Beim Atari TT liefert der externe SCSI-Anschluß keine TERMPOWER. Wenn sie an dem externen SCSI-Anschluß Geräte anschließen, so muß mindestens ein Gerät TERMPOWER liefern. Alternativ dazu können Sie an Ihrem TT auch TERMPOWER für den externen Anschluß nachrüsten. Dazu lötet man einfach an Pin 25 der SCSI-Buchse eine Sicherung mit 1 Ampere und eine Diode zu einer beliebigen Stelle mit 5 Volt.

Hostapter und SCSI-Gerät

Es gibt immer wieder Fälle, in denen ein Hostadapter nicht mit einem bestimmten SCSI-Gerät arbeitet. Diese Inkompatibilitäten liegen an den Hostadaptern und können nur durch ein Update des Hostdapters oder einen anderen Hostadapter behoben werden.

Einige Beispiele, bei denen es Probleme gab:

ALIA mit GAL-Versionen unter 2.3/4.3 arbeitet nicht mit Tandberg TDC 3620

Hard&Soft vantage1 arbeitet nicht mit Tandberg TDC 3660, zumindest ein Fall ist davon bekannt.

Wenden Sie sich bei derartigen Problemen am besten an den Hersteller des Hostadapters, ob es neuere GAL-Versionen gibt, bei denen dieses Problem eventuell nicht auftritt.

Die Spannungsversorgung

Es ist zwar selten, aber es gibt SCSI-Geräte die getrennte Kreise für 5 und 12 Volt haben. Bei solchen Geräten müssen unbedingt beide Masseanschlüsse am Versorgungsstecker angeschlossen sein. Dies ist z.B. beim HP-DAT so, wenn nur ein Masseanschluß verbunden ist, funktioniert das Gerät nicht.

Zusammenfassung

Das waren die wichtigsten Grundlagen zum Verständnis des Ablaufes auf dem SCSI-Bus. Wie man sieht, ist das relativ einfach und kaum kompliziert. Hat man erst mal den grundsätzlichen Ablauf auf dem SCSI-Bus erkannt, so ist es auch kein weiteres Problem die Leistungsfähigkeit des SCSI-Bus zu überschauen.

Betrachtet man Festplatten jedoch als reinen Datenspeicher und hat man mit Streamer, CD-Brenner, Scanner und ähnlichem nichts zu tun, so kann man sich das natürlich sparen (wie man in der DOSenwelt ja sehen kann), aber wenn man etwas mehr macht, als nur mal eben auf eine Festplatte zuzugreifen, dann lohnt es sich wirklich sehr, mit SCSI zu arbeiten.

Wer weiteres Interesse hat, sollte sich mal mit der SCSI-Norm auseinandersetzen. Sie ist öffentlich erhältlich und steht auch als Hypertext für ST-Guide zur Verfügung.

Was denn noch?

Im ersten Teil haben wir den prinzipiellen Ablauf der Kommunikation auf dem SCSI-Bus gesehen. Wer das aufmerksam gelesen hat, wird sich eventuell fragen, was der ganze Aufwand bei SCSI soll. Auch ohne Arbitrierung, Identifikation, Messages und das ganze Brimborium kann man doch auf Geräte zugreifen, wie man ja z.B. beim IDE-Port sehen kann.

Wenn Sie nun diesen Artikel in Ruhe lesen, und es auch einigermaßen verstanden haben (ganz ruhig, das ist halb so schwierig), dann wissen sie wirklich, was mit SCSI los ist, und vor allem, was damit möglich ist.

Solange man ein simples System hat, wie zum Beispiel DOS oder auch TOS ohne Multitasking, stimmt das auch, aber bei leistungsfähigeren Systemen sieht das anders aus.

Dazu betrachten wir mal den Betrieb mit mehreren Rechnern, oder mit mehreren Prozessen, die auf die Geräte zugreifen sollen.

Leistungssteigerung durch geschickte Busnutzung

Mehrere Initiatoren

Initiatoren sind SCSI-Geräte, die eine Aktion auf dem SCSI-Bus auslösen. Normalerweise handelt es sich dabei um die Computer auf dem SCSI-Bus, es können aber auch andere Geräte sein, zum Beispiel ein Streamer, der ein Copy-Kommando abarbeitet. Allgemein spricht man daher eben nicht von Computern, sondern von Initiatoren.

Spricht ein Gerät ein anderes an, so ist das angesprochene Gerät das Target, das Ziel der Ansprache.

Für die meisten Benutzer dürfte die Anwendung interessant sein, mehrere Computer gemeinsam auf einem SCSI-Bus zu betreiben. Der Sinn der Sache ist dabei, die SCSI-Geräte für beide Rechner benutzen zu können, ohne diese Geräte doppelt kaufen zu müssen.

Im wesentlichen geht es dabei um Streamer, Scanner und CD-ROMs. Festplatten kann man natürlich auch von beiden Rechnern aus benutzen, aber dabei treten logische Probleme auf, die der Anwender beachten muß.

Beim Zugriff auf Festplatten werden einige Daten gecachet, d.h. Daten, die bereits von der Platte gelesen wurden, und auf die erneut zugegriffen wird, werden im Speicher gehalten, und bei einem erneuten Zugriff müssen diese Daten nicht neu eingelesen werden. Wenn nun zwei Rechner auf die gleiche Partition auf der gleichen Festplatte zugreifen, führt dies unweigerlich zu einer Zerstörung der Daten auf der Platte, Verzeichnisse werden fehlerhaft zurückgeschrieben, weil der eine Rechner eine Änderung gemacht hat, von der der andere nichts weiß. Solange man aber immer nur mit einem Rechner zugreift, oder jeder seine eigene Festplatte hat, und die des anderen in Ruhe läßt, gibt es dieses Problem nicht.

Genauso gilt dies natürlich auch bei anderen Geräten, man kann logischerweise nicht von beiden Rechnern aus gleichzeitig ein Backup auf den Streamer machen.

Aber um zu SCSI zurückzukommen: dank des SCSI-Protokolles kann ohne Probleme der eine Rechner auf seiner Festplatte arbeiten, und quasi gleichzeitig der andere Rechner auf der seinigen, und dabei zum Beispiel ein Backup auf den Streamer durchführen.

Zunächst ist es ja so, daß mehrere Rechner gleichzeitig den SCSI-Bus beanspruchen. Damit es dabei nicht zu Problemen kommt, gibt es wie im ersten Teil des Artikels bereits erklärt, die Arbitrierung. Die Arbitrierung ist aber dabei nicht alles. Zwar reicht das bereits aus, um einen störungsfreien Betrieb zu erhalten, aber die Leistung des Systemes ist dabei nicht optimal. Betrachten wir mal den genannten Fall des Backups auf einen Streamer. Rechner A sei der Rechner, der Daten von einer CD-ROM auf seine Festplatte kopiert, und Rechner B schreibt gerade ein Backup auf den Streamer.

SCSI unterfordert?

CD-ROM und Streamer sind beides Geräte, die ihre Daten relativ langsam vom Medium lesen, oder darauf kopieren. Relativ langsam heißt hier, daß die Daten wesentlich schneller über den SCSI-Bus transportiert werden können. Betrachten wir einen etwas moderneren SCSI-Bus mit 8 Bit Breite und FAST-SCSI, so können die Daten mit bis zu 20MB/sec übertragen werden, während das CD-ROM mit etwa 1,5 MB/sec die Daten lesen kann, und der Streamer mit ca 200 kB/sec. Dadurch würde der Bus unnötig belegt, wenn man Daten anfordert, und der Bus solange belegt bleibt, bis die Daten komplett geliefert wurden.

Um diese unnötige Verzögerung zu vermeiden, gibt es die Möglichkeit zum Disconnect. Dabei gibt das Target den Bus frei, bis es die Daten überhaupt vom Medium gelesen hat, und meldet sich dann beim Initiator zurück, um die Übertragung auszuführen.

Der Ablauf wird dabei über Messages ausgeführt. Zunächst mußte vom Initiator bei der Übertragung des Kommandos ATN gesetzt werden, um dem Target anzuzeigen, daß man eine Message - heißt ja eigentlich Nachricht, aber schließlich geht es hier um SCSI - abgeben möchte (s. SCSI-enträtselt, Teil 1) . In der daraufhin vom Target eingeleiteten Message-Out-Phase verschickt der Initiator ein Message-Byte mit einer Identify-Message.

===================================================================
| Bit|   7    |   6    |   5    |  4   |  3   |  2   |  1   |  0   |
|==================================================================|
|    |Identify|DiscPriv| LUNTAR | Res. | Res. |      LUNTRN        |
===================================================================

Dabei ist das Bit 7 gesetzt, was kenntlich macht, daß es sich bei der Message um `identify' handelt. Je nach dem, ob Bit 6 gesetzt ist oder nicht, teilt der Initiator mit, daß das Gerät einen Disconnect ausführen darf, falls es dies für sinnvoll hält.

Danach kann es halt passieren, daß das Target irgendwann eine Message-In-Phase einläutet, und darin dem Initiator mitteilt, daß es einen Disconnect ausführen möchte (Messagebyte 04h). Wenn der Initiator nichts dagegen hat (er könnte mit einer sofortigen Messagephase und der Antwort-Message 'MESSAGE-REJECT' den Disconnect ablehnen) wird der Bus daraufhin freigegeben, und irgendwann wird sich das Gerät mit einem Reconnect zurückmelden. Der Reconnect läuft dann genauso, wie eine komplette Selektion eines Initiators an ein Target, also mit Arbitrierung um den Bus und anschließender Selektion des Initiators durch das Target. Obwohl hier nun die Selektion vom Target duchgeführt wird, wird das Target jetzt nicht als Initiator bezeichnet, um keine Verwirrung entstehen zu lassen. Sonst müßte man ja immer beachten, wer nun einen Reconnect durchgeführt hat.

Wann denn nu?

Eine kleine Frage am Rande ist natürlich dabei das Kriterium, wann das Target einen Disconnect, und wann es einen Reconnect durchführt. Oben hatte ich das noch als 'falls es das für sinnvoll hält' abgetan. Dazu gibt es natürlich (wer hätte jetzt etwas anderes erwartet) eine Möglichkeit, dies bei dem Gerät zu erfragen, oder auch einzustellen.

Dazu gibt es eine Parameterseite - man nennt das `mode page' - die mit dem Kommando `Mode Sense' gelesen und mit `Mode Select' geändert werden kann.

Im wesentlichen gibt es dort zwei Dinge, die die Disconnect und Reconnect-Bereitschaft steuern, zum einen ist es eine Angabe für den Füllungsgrad der Puffer auf der Platte (das Plattencache), wann jeweils ein Reconnect beim Schreiben (die buffer empty ratio) oder ein Reconnect beim Lesen (buffer full ratio) ausgeführt werden soll. Als zweites gibt es eine Grenze, die angibt, wie lange der Bus belegt bleiben darf, ohne das Daten über den Bus transportiert werden. Wird diese Zeit überschritten, führt das Target ebenfalls einen Disconnect aus.

Die komplette Erklärung entnehmen sie am besten der SCSI-2, Abschnitt 8.3.3.2 Disconnect-Reconnect page.

Es besteht übrigens auch für den Initiator die Möglichkeit, von sich aus einen Disconnect einzuleiten, dazu muß er halt ATN setzen und in der daraufhin folgenden Message-Out-Phase die Message DISCONNECT verschicken.

So, und nun machen wir am besten eine kurze Pause, und denken mal darüber nach, was uns das nun bringt. Falls Sie das nun nach der Erklärung noch nicht raus haben, sollten sie den bisherigen Teil des Artikels vielleicht noch mal lesen. Alternativ kann ich es natürlich auch erklären.

Na, noch nicht klar?

Ok, der Sinn der Sache ist natürlich, daß beide Geräte nur soviel den SCSI-Bus benutzen, wie nötig ist. Bei dem Beispiel eines Streamers und eines CD-ROM haben wir eine gesamt zu übertragende Datenmenge von etwa 1,7 MB/sec. Ein 'normaler' SCSI-Bus kann aber schon 5 MB/sec übertragen. Würde der Bus dabei permanent belegt, hätte man eine erheblich geringere Leistung beim Zugriff auf die Geräte.

Mehrere Tasks

Im Prinzip sieht es genauso aus, wenn man mit mehreren Programmen von einem Rechner aus auf die Geräte zugreifen möchte. Um das ganze zu verallgemeinern, betrachten wir jedoch nicht unbedingt Programme, sondern Tasks, den Grund werden wir später noch sehen.

Stellen Sie sich vor, ein Programm kopiert gerade Daten von der CD auf die Festplatte, und ein anderes möchte gerne Daten von der Festplatte lesen.

Die Situation ist die gleiche, wie bei mehreren Rechnern auf dem SCSI-Bus, nur das die Programmierung etwas schwieriger ist. Hierbei muß eben der SCSI-Treiber dafür sorgen, daß ein zweites Programm erst dann auf die SCSI-Schnittstelle zugreift, wenn das erste Programm fertig ist, oder eben gerade ein Disconnect aufgetreten ist.

Solange das CD-ROM die Daten noch nicht in seinem Puffer hat, kann das andere Programm weiterhin Daten lesen und weiterarbeiten. Bei Betriebssystemen, die dies wirklich nutzen können, ist der Unterschied frappierend. Ein sehr gutes Beispiel dafür ist Linux, man merkt in der Task, die auf die Festplatte zugreift fast gar nicht, daß jemand anderes da auch noch auf dem Bus arbeitet. Eine vielgestellte Frage zu SCSI ist aus diesem und dem vorhergehenden Abschnitt auch einfach zu beantworten: wozu werden SCSI-Geräte unter anderem mit ihrer maximalen Transfergeschwindigkeit auf dem SCSI-Bus angegeben? Liest man bei einem CD-ROM davon, daß es bis zu 20 MB/sec übertragen kann, denkt man doch zunächst, daß dies keine Vorteile bringt, können die schnellsten CD-Laufwerke doch gerade 3 MB pro Sekunde von der CD lesen. Angesichts der Tatsache aber, daß man aufgrund der kürzen Übertragungszeiten den Bus länger freigeben kann, ist der Sinn einer solchen Angelegenheit klar.

Wer kann's?

Leider haben wir auf dem Atari bisher nicht die Möglichkeit dies wirklich auszunutzen. Prinzipiell bietet Magic zwar die Möglichkeit dazu, aber bisher ist es nicht nutzbar. Wie beim vielbeschworenen Hintergrundtransfer - der übrigens nur geringe Vorteile bietet - kann man den Disconnect benutzen, um während des Disconnect Rechenzeit an andere Programme freizustellen. Vom Disconnect bis zum Reconnect kann man immerhin Zeit abgeben, aber einen vollen Disconnect, währenddessen andere Programme auf andere Geräte zugreifen können, gibt es leider noch nicht. Immerhin merkt man dabei, daß man zum Beispiel während eines längeren Kopiervorganges von einer CD in anderen Programmen weiterarbeiten kann, aber mehr geht leider noch nicht. Einen Teil kann man sich aber nutzbar machen, GEMAR kann zum Beispiel einen getrennten Thread für das Schreiben auf den Streamer benutzen. Dabei merkt man den Vorteil deutlich, wenn man den Streamer an einem anderen Bus hat, als die Festplatte, von der die Daten kommen. Es kann daher sinnvoll sein, ein langsameres Gerät, wie den Streamer oder das CD-ROM auf den ACSI-Bus zu legen, während die Festplatten an SCSI angeschlossen sind.

Queuing

Disconnect ist nicht alles, was SCSI bietet. Die nächste interessante Möglichkeit zur Leistungssteigerung ist das Command-Queing. Dabei werden mehrere Kommandos an das SCSI-Gerät geschickt, das dann entscheidet, in welcher Reihenfolge die Kommandos abgearbeitet werden.

Voraussetzung dazu ist, daß ein Disconnect aufgetreten ist. Währenddessen ist ja der Bus frei, und statt eines Kommandos an ein anderes Gerät, kann bereits das nächste Kommando abgeschickt werden. Das SCSI-Gerät kann dann entscheiden, in welcher Reihenfolge die aufgelaufenen Kommandos bearbeitet werden.

Um den Zusammenhang zwischen den Kommandos herzustellen - man muß ja wissen, zu welchem der laufenden Kommandos ein Reconnect gehört - werden ebenfalls Messages benutzt. Dazu bezeichnet der Initiator nach der Identify-Message, die ja im unmittelbaren Anschluß an die Kommando-Übertragung versandt wird, mit einer weiteren Message das laufende Kommando mit einer eindeutigen Nummer. Diese Nummer bezeichnet den laufenden Kontakt - man nennt das Nexus - um einen eindeutigen Bezug herstellen zu können.

Nach einem Reconnect meldet das Target wiederum diese Nummer, um den Nexus zu identifizieren, mit dem der Betrieb jetzt weitergehen soll.

Was das Target aus dem Queing macht, ist ihm überlassen. Eine denkbare Optimierung ist zum Beispiel zwei SCSI-Zugriffe auf die gleichen Blöcke der Festplatte.

In diesem Fall kann das Gerät die gleichen Daten an beide Zugriffe zurückliefern, und muß sie nur einmal vom Medium lesen. Bei einem Zugriff, der mehr Daten übertragen soll, als in das Cache des Gerätes passen, spart es erhebliche Zeit, die Daten jeweils in den Puffer zu lesen, und dann zweimal mit voller Geschwindigkeit, die der Bus hergibt, an die zwei laufenden Zugriffe zu übertragen. Selbstverständlich könnte man dies auch im Treiber durchführen, aber dort wäre es logisch erheblich schwieriger unterzubringen, da SCSI-Kernroutinen normalerweise nichts über die verschiedenen Geräte und ihre Verhaltensweisen wissen. Eine Festplatte und ein CD-ROM haben da zum Beispiel normalerweise erheblich unterschiedliche Datenaufbauten, was zu unterschiedlichen Strategien des Caching führen kann. Das Gerät dagegen weiß schließlich am allerbesten, was es macht und wie es aufgebaut ist, kann also besser handeln.

Andere Messages

BUS DEVICE RESET

Um ein Gerät einzeln zurückzusetzen, ohne das andere Geräte davon betroffen sind, wie es beim Setzen der Reset-Leitung auf dem SCSI-Bus ist, kann man eine RESET-Message an ein Gerät versenden.

Das Gerät verfährt dann, als hätte es einen `har reset' erhalten, verwirft alle laufenden Transfers, Command Queues, Geräte-Reservierungen, Konfigurationen und was sonst noch so ansteht.

Außerdem liefert das Gerät dann beim nächsten Zugriff `Unit Attention', damit alle erfahren, daß der Zustand des Gerätes nicht mehr gültig ist.

ABORT

Aus verschiedenen Gründen ist es sinnvoll, ein laufendes Kommando abbrechen zu können. Ein wesentlicher Grund wäre zum Beispiel, daß man vom Initiator aus einen präventiven Lesezugriff machen möchte, um maximale Datenraten zu erreichen. Dabei würde ein Treiber mehr Daten von der Platte anfordern, als eigentlich ursprünglich benötigt werden. Der Grund dafür ist die Erwartung, daß die Daten, die den ursprünglich angeforderten folgen, wahrscheinlich in Kürze auch angefordert werden. Ein gutes Beispiel dafür sind Harddiskrecorder. Dabei ist normalerweise davon auszugehen, daß die Daten auf der Festplatte komplett Sektor für Sektor benötigt werden. Damit der SCSI-Overhead, der durch Arbitrierung, Selektion, Kommandoübertragung und den ganzen Rattenschwanz zusammenkommt, nicht einen so hohen Anteil an der Übertragungsdauer hat, werden bei solchen Geräten immer sehr große Datenmengen angefordert.

Falls dann jedoch dies plötzlich nicht eintritt, zum Beispiel, weil der Anwender auf einmal am Jogshuffle rumdreht (dieser vorwärts-rückwärts-Hebel zum suchen einer Musikposition) stellt sich ja unerwarteterweise heraus, daß die angeforderten Daten gar nicht benötigt werden, aber dafür ganz andere.

Um nicht die Restzeit des laufenden Kommandos abwarten zu müssen, bricht man einfach das laufende Kommando ab, indem man eine ABORT-Nachricht an die Festplatte versendet. Die Platte führt das laufende Kommando nicht zu ende, und man kann das neue Kommando absetzen.

Mit ABORT kann man so natürlich auch laufende Kommandos abbrechen, die sonst nicht abbrechbar erscheinen, zum Beispiel das Formatieren einer Festplatte.

WIDE DATA TRANSFER

Ein häufig anzutreffender Aberglaube betrifft die Vermutung, daß auf einem weiten SCSI-Bus - also 16 oder 32 Bit breit - bereits ein vorhandenes 8-Bit-Gerät die weiten Transfers der weiten Geräte unterbindet.

Dem ist nicht so, weil ein weiter Transfer erst dann durchgeführt wird, wenn einer der beiden Teilnehmer einen weiten Transfer anfordert. Dazu wird einfach die Message WIDE DATA TRANSFER REQUEST (WDTR) verschickt, die dann entweder akzeptiert wird, indem mit einer entsprechenden WDTR-Message geantwortet, oder mit der Message MESSAGE REJECT abgelehnt wird.

Der erste, der die Nachricht überträgt, meldet dabei seine maximale Transferweite, und der antwortende meldete seine Weite, jedoch maximal die, die vom ersten gemeldet wurde. Die zulässige Breite ist damit ausgehandelt, und kann bis auf weiteres benutzt werden.

Damit diese Nachricht nicht jedesmal übertragen werden muß, gilt sie solange als ausgehandelt, bis sie ungültig wird (ach was).

Ungültig wird dieser Zustand durch

  • einen Hard Reset (setzen der Resetleitung auf dem Bus)
  • ein Device Reset (per Message BUS DEVICE RESET)
  • einen Power On-Zyklus (also ab- und anschalten eines der Geräte.

Damit kann man also auch ein Wide-SCSI-Gerät ohne Probleme an einen 8-Bit-Bus anschließen. Da die Anforderung nicht bestätigt wird, wird eben nur mit 8 Bit Breite übertragen.

Dieser Wert wird übrigens für jedes Gerät getrennt ausgehandelt, damit immer zwei Geräte miteinander das maximal mögliche nutzen, und nicht ein langsames Gerät alle anderen ausbremst.

SYNCHRONOUS DATA TRANSFER REQUEST

Ähnlich wie bei der WDTR-Message, geht es bei der SYNCHRONOUS DATA TRANSFER REQUEST (SDTR) Message um das Aushandeln maximaler synchroner Transferraten.

Dabei handeln die Geräte eben aus, mit welcher synchronen Rate die Daten übertragen werden können.

Genauso wie bei WDTR gilt diese Aushandlung solange, bis einer der genannten Fälle die Absprache ungültig macht.

Verschiedenes

SCSI ist zu komplex, um es in einem Artikel komplett auszubreiten. Nachdem man die Grundzüge verstanden hat - ich hoffe das ist jetzt so - ist es jedoch so, daß man die auftretenden Fragen problemlos anhand der Norm beantworten kann.

Einige Themen, die jedoch immer wieder aufkommen, will ich jedoch noch in loser Sammlung behandeln.

Unit Attention

Immer wieder stolpern Anwender über die Frage, was `Unit Attention' bedeutet, bzw. was mit einem Jumper einer Festplatte zu machen ist, mit dem man `Unit Attention' abschalten kann.

Im wesentlichen ist Unit Attention nur ein Status, der eine Gruppe von bestimmten Zuständen zusammenfaßt. Prinzipiell liefert jedes Gerät nach eine Zugriff ein Status-Byte, das entweder besagt, daß alles in Ordnung ist, oder das ein Fehler aufgetreten ist. Das Bit 1 im Status bedeutet dabei `Check Condition', man soll also nachfragen, was wohl los ist.

Dazu wird das Kommando `Request Sense' benutzt, das eine recht genau aufgeschlüsselte Fehlermeldung liefert. Darin steht nun zunächst, daß es sich um Unit Attention handelt, sowie eine weitergehende Information über den Grund dafür. Üblich sind dabei eben, daß das Gerät gerade eingeschaltet wurde, oder das ein Reset auftrat, oder daß ein Medium gewechselt wurde (wenn es ein wechselbares Medium ist). Eine Änderung der Laufwerksparameter, wie sie mittels Mode Select möglich ist, führt ebenfalls dazu.

Im allgemeinen handelt es sich also um Fehlermeldungen, die mit irgendwelchen Zustandsänderungen des Gerätes zusammenhängen.

Für einen Treiber ist dies wichtig, weil damit alle Absprachen mit dem Gerät neu erfolgen müssen. Für Wechselplatten muß eben die neue Partitionsstruktur eingelesen werden, bei Geräten, mit denen synchrone oder weite Transfers abgehandelt waren, müssen diese erneuert werden.

Für Atari-Anwender ist dies insofern interessant, daß ein Gerät mit eingeschalteter Unit Attention auf Reset und `Power On' erst mit einem TOS ab 2.06 bzw. 3.06 gebootet werden kann. Dies liegt daran, daß ältere Versionen von TOS nur einen Versuch machen, von einem Gerät zu booten. Schlägt dieser fehl (eben durch die Unit Attention), wurde das Gerät als nicht bootbar eingestuft. Neuere TOS-Versionen machen dann einfach einen zweiten Versuch, der dann auch problemlos klappt.

Übrigens werden Fehlermeldungen immer an alle Initiatoren gemeldet, die von dieser Meldung betroffen sind. Dies ist auch ein Grund, warum Identifikation bei der Selektion Pflicht ist (siehe Teil 1 dieses Artikels), denn das Gerät muß wissen, an wen die Meldung bereits geliefert wurde. Fehler, die einen Zugriff betreffen - zum Beispiel ein Lesefehler - werden nur an denjenigen gemeldet, der den Fehler ausgelöst hat.

Prioritäten

Bei der Vergabe des Busses in der Arbitrierungsphase haben die Geräte ja Prioritäten, die der ID des Gerätes entsprechen (s. Teil 1). Ein sinnvoller Feintrimm der Leistung des SCSI-Busses ist daher die sinnvolle Vergabe der SCSI-Ids.

Im allgemeinen braucht man darum keine Sorge zu tragen, in besonderen Fällen kann es sich jedoch lohnen.

Benutzt man zum Beispiel einen CD-Brenner in einem System mit echt genutzten Disconnects, daß also andere Tasks während des Disconnect den Bus benutzen können, ist es sinnvoll, dem Brenner eine höhere SCSI-Id zu geben, als dem Host.

Der CD-Brenner gibt nämlich den Bus per Disconnect frei, solange er genügend Daten im Puffer hat. Während der Bus frei ist, kann ein Thread des Brennvorganges - normalerweise handelt es sich um getrennte Threads für das Schreiben und das Einlesen der Daten - weitere Daten von der Platte lesen und zum Brennen aufbereiten.

Will nun der Brenner einen Reconnect durchführen, und gleichzeitig der Rechner weitere Daten sammeln - oder auch ein anderes Programm auf die Platte zugreifen - gewinnt der Rechner mit der höheren ID den Bus, womit der Brenner warten muß, bis der Bus wieder frei ist. Zwar führt dies nicht sofort zu einem `Buffer Underrun', aber damit wird immerhin das Risiko erhöht. In kritischen Fällen, in denen man knapp an der Grenze liegt, kann es ausreichen, den Brenner auf eine höhere ID zu legen, als den Hostadapter. Mit Sicherheit führt das nicht dazu, daß ein System, mit dem man kaum schafft, CDs zu brennen, auf einmal ohne Probleme durchkommt, aber immerhin ist es ein Sicherheitsgewinn. Tests beim Brennen von CDs mit gleichzeitig starker Belastung des SCSI-Bus, zeigen eindeutig diese Besserung, leider ist der Grenzzustand jedoch nur sehr schwierig herbeizuführen, daher kann man es nicht so einfach mit einem kurzen Test nachvollziehen.

Was bringt's?

Auf dem Atari haben wir leider von einigen der Möglichkeiten keinen Nutzen. Disconnect und dessen Vorteile bei mehreren Programmen können wir genauso wenig nutzen, wie Command-Queing. Aber seien wir doch ehrlich, die Tage von TOS sind gezählt, wie auch immer wir uns dagegen sträuben.

SCSI dagegen wird uns noch lange begleiten, solange wir es nur wollen. Natürlich kann ich mir die nächstbeste Billig-DOSe kaufen, und dabei nur IDE verwenden, aber wer das macht, besonders im Hinblick auf leistungsfähigeres als Windows 95, vergibt halt einfach einige Vorteile, die er sonst hätte.

Insbesondere bei der Betrachtung der wirklich leckeren Features, die andere Systeme haben - z.B. RAID 0 unter NT - kann man schnell erkennen, welche Vorteile SCSI bietet.

Ein jeder darf Leistung verschenken, soviel er will, aber ich will einfach nicht. Und deswegen kommt mir nichts anderes als SCSI in's Haus, jedenfalls nicht für die primären Geräte.