Verwendung SCSI-CD-Rom

SCSI-Laufwerke waren früher die ersten verfügbaren CD-Laufwerke mit herstellerunabhängigem, standardisiertem Interface, sonst gab es nur herstellerspezifische CD-Laufwerksinterfaces (beispielsweise von Sony, Mitsumi und Panasonic). Mit dem Aufkommen von IDE-Laufwerken hat sich das aber auch relativiert.

Außerdem bot SCSI zur damaligen Zeit neben einer höheren Datenübertragungsrate (gegen über IDE) auch den Vorteil, bis zu 7 Laufwerke (bzw. sogar 15 bei der "Wide SCSI"-Variante) an einem SCSI-Bus anzuschließen.

Dieser "Zwischenstecker", den du da beschreibst, ist ein Terminator - ein Abschlusswiderstand. Der gehört an das physische Ende des SCSI-Kabels

Letztendlich war SCSI in der Regel für "Professionelle Computer" (Server, RISC-Server/Workstation usw.) genutzt worden, da die Laufwerke in der Regel teurer waren als ihre IDE-Pendants (sofern verfügbar).

Und es war zum großen Teil Hotplug fähig..

ausserdem entlastet es die cpu, weil der controller schon sämtliche datenverarbeitung übernimmt. ide war halt doch immer mehr oder weniger bitbanging

seh ich auch so

Zitat von Gruni

ausserdem entlastet es die cpu, weil der controller schon sämtliche datenverarbeitung übernimmt. ide war halt doch immer mehr oder weniger bitbanging

Das hängt vom Treiber ab, bei Adaptec stimmt das, weil die Controller meistens DMA-Transfers konnten. Es gab aber auch "Arme-Leute"-SCSI-Lösungen, die genauso CPU-lastig liefen wie beim alten IDE. DMA ging bei IDE natürlich auch ab UDMA und beim proprietären Mitsumi-Interface auch schon immer.
Nachteil bei SCSI war häufig, daß die Treiber unter DOS einiges an RAM belegten.

ja, wobei die arme-leute-scsi-karten ja hauptsächlich als bessere scanner-interfaces konzipiert sind. eigentlich alle richtigen scsi-controller unterstützen ja dma

Die Ressourcenbenutzung von SCSI-Treibern kann man sich sehr gut anhand der Windows-9x-Bootdiskette vor Augen führen, deren Hauptbestandteil neben den DOS-Kerndateien Treiber für SCSI-CD-ROM-Laufwerke waren. Als mir das klar wurde, entpuppte sich die Behauptung, dass die Bootdiskette die aktuelle Hard- und Softwareausstattung eines Systems widerspiegelt und daher regelmäßig erstellt werden soll, als Luftnummer.

Wie oreissig schon mal erwähnt hatte, ist ATAPI (ATA with Packet Interface) eigentlich auch nur ein Standard, um die SCSI-Befehle, die die CD-ROM-Laufwerke ohnehin verstehen, auch über IDE benutzen zu können.

Nicht zu vergessen, dass das Speichercontroller-Interface moderner Betriebssysteme (Windows NT, Linux, FreeBSD mit CAM-Treibern…) auf SCSI aufbaut.

Bei Linux werden die Geräte mittlerweile egal welcher Anschluss auch als "SCSI" angesprochen (auf Dateiebene)
Früher gab es z.B. hda für IDE 1.Master und sdb für das 2. SCSI-Laufwerk, mittlerweile ist alles s*, z.B. auch die optischen Laufwerke schlicht srX oder scdX

hat man das nicht aber während der vollständigen implementierung von sata eingeführt, sodass sd* auch für sata stehen könnte? ich meine da wär mal was gewesen.

abgesehen davon ja, usb disks und cardreader wurden unter linux schon immer (zumindest seit kernel 2.6, wurden die vorher überhaupt schon von haus aus unterstützt?) über eine scsi-emulation angesprochen...

die meisten treiber auf der bootdiskette sind auch etwas übertrieben. die meisten richtigen scsi-controller bieten die emulation eines optischen laufwerks als festplatte oder zumindest als standard-atapi-laufwerk...

Zitat von Gruni

hat man das nicht aber während der vollständigen implementierung von sata eingeführt, sodass sd* auch für sata stehen könnte? ich meine da wär mal was gewesen.

Das geschah bereits mit der Veröffentlichung von Linux 2.6 (also noch lange vor den ersten SATA-Platten), als man als Ersatz für die alten IDE-Treiber libATA im Linux-Kernel einführte. Lediglich Debian und einige andere Linux-Distros hatten noch lange einen Patch, der udev dazu verlasste, IDE-Geräte klassisch als hda, hdb etc. zu benennen. SATA-Geräte im PATA-Emulationsmodus laufen nach wie vor über diese Bibliothek, der AHCI-Modus war eh schon immer wie SCSI gehandelt worden.

Zitat von mrshadowtux

Bei uns im Rechenzentrum haben das sehr viele Server. Es wird aber nach und nach von SAS abgelöst. Der PC-Händler hat Mist erzählt.

SAS ist SCSI! Serial Attached Scsi. Ist sogar abwärtskompatibel zu Sata, spricht Sata Laufwerke funktionieren auch an einem SAS-Controller ( aber nicht umgekehrt ).
SCSI ( SAS ) hat nach wie vor seine Existensberechtigung vor allem im Serverbereich, wo es auf lange Dauerlaufzeiten bei Festplatten ankommt.

Zitat von mrshadowtux

Jo, SAS ist protokolltechnisch SCSI. Aber halt nicht parallel angebunden.

Ich ich habe mich schon gewundert warum es Serial... heist

Zitat von mrshadowtux

Jo, SAS ist protokolltechnisch SCSI. Aber halt nicht parallel angebunden.

aber soweit ich weiß kann man auch einfach SATA Platten ranhängen. SCSI ist tot. Nur bei sehr alten Rechner vor dem Pentium lohnt es sich, weil man große Platten und CD-Boot realisieren kann. Letzteres je nach controller.

Zitat von Dirk

Nur bei sehr alten Rechner vor dem Pentium lohnt es sich, weil man große Platten und CD-Boot realisieren kann. Letzteres je nach controller.

Nicht zwangsläufig. Ich hab ja einige Ultra 160-Platten hier im aktiven Einsatz (und auch eine Ultra 320!), leistungstechnisch kann da keine herkömmliche IDE-Platte mithalten Für manche Anwendungen (beispielsweise Bandlaufwerke) gibts auch quasi keine andere Alternative als SCSI (bzw. jetzt vielleicht SAS).

SCSI ist halt quasi das bessere IDE, und damit aber natürlich genauso tot wie IDE auch, weil sich mit parallelen Schnittstellen eben nicht so einfach hohe übertragungsraten wie mit seriellen erreichen lassen.

wegen "SAS ist SCSI"...SCSI ist ja mehr als die Befehle, sondern vor allem beschreibts einen parallelen Bus. Ich weiß nicht genau, wie das bei SAS ist, aber SATA ist ja kein Bus, sondern eine punkt-zu-punkt verbindung. Wenn man mit dem Protokoll argumentiert, dann ist auch IDE (=> ATAPI), Ethernet (iSCSI) und USB (von dem Faktor wie es angesprochen wird im OS) genau das gleiche wie SCSI