Ich denke wenn ATAPI die Geschwindigkeit damals nicht raufgeschraubt hätte, würden wir heute für SCSI-Drives genau sowenig bezahlen wie jetzt für die IDE Platten und keine Schwein würde mehr was von IDE wollen.

Für mich gibts in einem Server keine Alternative, den Aufpreis ist es auf jeden Fall Wert IMHO.

cu

Adrian
--
@ OS/2 Netlabs

-------
The OS/2 OpenSource Project:
http://www.netlabs.org

in einem Server keine Alternative

1. IDE-Drives sind im vergleich zu SCSI derart lächerlich billig, dass man den Ausfall problemlos einkalulieren kann
2. für Webserver und ähnliche Spielchen sind IDE-Platten immer schnell genug: Die paar Daten, die häufig angefragt werden, passen meist in den Arbeitsspeicher. die fancy SCSI-Features (auf dem Bus Daten kopieren) nutzen hier nichts, es sei denn, du kannst 'ne Netzwerkkarte mit SCSI-Interface vorweisen. Ok, bei richtig fetten Fileservern könnten die Zugriffzeiten anfangen 'ne Rolle zu spielen und der Umstand, dass es AFAIK keine PCI 2.2 Adapter für IDE gibt.
3. bei Datenbankanwendungen wird SCSI IMHO eigentlich nur nötig, wenn der Programmierer mit SQL auf dem Kriegsfuss steht, die Datenbank nur als File mit guter Suchfunktion nutzt. Ok, gute Programmierer sind immer knapp, für Datenbanken mag SCSI wegen der besseren Zugriffzeiten noch 'ne Alternative sein. Plus das PCI 2.2 Argument für fette Server.

IDE-Drives sind im vergleich zu SCSI derart lächerlich billig, dass man den Ausfall problemlos einkalulieren kann

Uh... entschuldige, aber hast du jemals in einer richtigen Serverumgebung gearbeitet? In meinen Augen disqualifizierst du dich mit dieser Aussage jedenfalls als SysAdmin. Glaub mir: Bei einem Harddiskausfall ist der Preis für eine neue Platte deine geringste Sorge.

Ok, bei richtig fetten Fileservern könnten die Zugriffzeiten anfangen 'ne Rolle zu spielen

Es mag dich überraschen, aber selbst auf einem stinknormalen Desktop bemerkt man den Unterschied, und wenn es nur der schnellere Bootprozess ist.

Klar, ob die höhere Performance und die geringere Ausfallswahrscheinlichkeit den massiv höheren Preis rechtfertigen, dass muss fallweise entschieden werden. Aber die Vorteile sind da.

Lies den tecchannel-Artikel. Da sind Beispiele drin. Und die SCSI-Platten haben dort komischerweise die besseren Werte (Hervorhebungen von mir):

Wie Western Digital gegenüber tecCHANNEL angab, basieren die Zuverlässigkeitsangaben ihrer IDE-Festplatten auf einer Laufzeit von 60 Stunden pro Woche. Im Monat entspricht das nur 240 Stunden und somit weniger als bei IBM mit einer POH-Angabe von 333 Stunden. Seagate-IDE-Festplatten werden im typischen Betrieb noch weniger genutzt. Zumindest nimmt der Hersteller dies bei der Auslegung seiner Festplatten an: 8 Stunden pro Tag und fünf Mal die Woche. Daraus resultiert eine durchschnittliche Laufzeit von 173 Stunden pro Monat.

Wäre eine IDE-Festplatte wirklich für den Dauerbetrieb geeignet und konzipiert, müsste der POH-Wert 732 Stunden pro Monat betragen. Davon scheint Maxtor auszugehen. Denn laut Thomas Astheimer, Manager Customer Engineering bei Maxtor, gibt es bei deren IDE- und SCSI-Festplatten keine qualitativen Unterschiede. Beide Laufwerksgattungen seien für den Dauerbetrieb ausgelegt. Ein Blick in die Datenblätter von Maxtors IDE- und SCSI-Festplatten weist allerdings doch ein paar Unterschiede auf. Während das aktuelle SCSI-Drive Atlas 10K III eine Ausfallrate von kleiner 0,9 Prozent verspricht, müssen IDE-Drives mit 1,0 Prozent auskommen.

Ok, man hätte mehr erwartet. Aber insbesondere bei der Aussage "keine qualitativen Unterschiede" wundert es einen doch.

Der FutureZone-Artikel ist recht kurz und dürftig. Der dort verlinkte tecchannel-Artikel (von Ende Juni) zu dem Thema ist recht ausführlich und geisterte letzte Woche durch's bei uns durch's IRC.

Ich habe ihn damals auch meinem Chef unter die Nase gehalten, weil wir in alle neueren Server und Router überall IDE-Platten drin haben. Er konnte das Problem mit der mangelnden Servertauglichkeit der IDE-Platten nicht nachvollziehen. Er meinte, er hätte bisher nur Probleme mit einem bestimmten Hersteller und das waren wohl sowohl IDE- als auch SCSI-Platten. Witzigerweise schwört er auf IBM, deren Platten ja die Diskussion, um die es in dem Artikel geht, ausgelöst hat.

Er meinte aber auch, daß so wie die meisten SCSI-Platten auf längere Laufzeiten als ihre IDE-Pendants entwickelt werden, so sind wohl die IDE-Platten auf mehr An- und Ausschaltvorgänge ausgelegt als ihre SCSI-Pendants, d.h. empfindlicher gegen häufiges Hoch- und Runterfahren sind. (Wie das jetzt aber Pro-IDE-im-Server sein sollte, habe ich auch nicht kapiert. :-)

Was mir wiederum zu denken geben sollte, weil ich zuhause fast ausschließlich SCSI-2-Platten habe. Aber außer Temparaturproblemen hatte ich bisher noch keinen Ärger...

^{P.S.: Wollte den tecchannel-Artikel eigentlich auch als einsenden, bin aber nicht zum fertiglesen gekommen und habe es wieder vergessen. :-/}

Sobald Zugriffszeiten zaehlen, weil man random auf Files zugreifft (Swap, Newsserver, SQL DB, Multiuser/Server, Compiler, Shellscripts) entscheidet es sich an der Zugriffszeit. Und da haben SCSI die Nase vorn. Und das ist auch warum die Drives teurer sind, weil sie schnelleren Zugriff haben.

Also nicht wegen dem Bus selber, sondern weil mit SCSI die in anderer Hinsicht besseren Drives kommen, weil fuer Server ausgelegt, weil eben Server Zugriff _und_ viele Disks (das braucht SCSI) haben.
--
Make your code truely free: put it into the public domain

Nicht nur das. Bei SCSI macht der Controller viel von der Rechenarbeit, die bei IDE der Prozessor mit übernehmen muss, insbesondere bei der Datenübetragung zwischen zwei Platten am selben, also z.B. CD-ROM auf CD-Brenner oder kopieren/verschieben zwischen zwei Partitionen: 'ne IDE-Kiste belastet sowas schon recht gut, 'ne SCSI-Kiste kann da nur müde lächenln.

Das ist -- neben 7 Geräten an einem Kabel -- das, was mir an SCSI so gefällt. Inbesondere, wenn die Kiste, so wie meine, schon etwas betagter (K5 mit 100 MHz :-) ist.

Bei SCSI macht der Controller viel von der Rechenarbeit, die bei IDE der Prozessor

• Das Datenkopieren selber kannst Du nicht mehr meinen: Das übernimmt seitdem die DMA-Transfermodi benutzt werden der DMA-Controller (in alten Rechnern) bzw. der PCI-Controller (heute).
• Datentransfers initieren? Bitte sehr, dass muss bei SCSI die CPU auch. Device-to-Device-Transfers?
• Gut. Wird wohl absolut haarig bei Master-zu-Slave-Transfers. Wer das weiss schliesst nur ein Gerät pro Kanal an. Wird mit Serial-ATA eh obligatorisch.
• Bei Device-to-Device-Transfers übernimmt fein sauber der Systembus, sprich der PCI-Bus das kopieren. Vollkommen autark von CPU, nachdem diese den Transfer initiert hat. Die CPU ist also bei beiden System fein raus. Der kleine Unterschied zwischen IDE- und SCSI-Transfers ist somit (neben dem Fakt, daß IDE auf den Punkt konzeptiert, wärend's bei SCSI sicher auch 'nen Opcode fürs Kaffeekochen gibt), daß bei SCSI das Datenschaufeln auf 'nem separaten Bus abläuft, während bei IDE der Systembus belastet wird. In der Realität leiter nur 133 MBit breit -- wird endlich Zeit, daß breitbandigere Varianten von PCI im PC Standard werden. Wie war das mit PCI 2.2, Hypertransport, X-PCI, ... Der IDE/PCI-Ansatz hat nämlich den Vorteil, daß
  1. die Architektur wesenlich einfacher (die SCSI-Specs umfassen tausende Seiten) und preiswerter ist (hat halt genau eine Kopierschlampe im ganzen System)
  2. PCI AFAIR im Gegensatz zu SCSI nicht blockiert, nur weil eine Gerät gerade aufdem Amoktrip ist oder schläft (Stichwort: Externe CD-ROM-Laufwerke, SCSI-Scanner, die den SCSI-Bus, somit die Systemplatte, somit das ganze System blockieren).

IDE im DMA oder UDMA Modus kommt schon recht nahe an SCSI heran. Trotzdem hat SCSI noch einige Vorteile.

Kleines Beispiel: Bei IDE ist die CPU vom Moment der Datenanforderung bis zum Abschluss der Lieferung blockiert (auch wenn die Lieferung per DMA erfolgt, kann die CPU während des Transfers nicht arbeiten). Wenn bei einem aktuellen SCSI-System eine Anfrage abgeschickt wird, so kann die CPU weiterarbeiten, während die Festplatte den entsprechenden Block sucht. Das ist insbesondere dann sehr wertvoll, wenn Arbeiten laufen, die gleichzeitig die CPU wie auch die Disks stark beanspruchen (etwa Videobearbeitung).

Übrigens: Das SCSI Protokoll ist sowieso noch lange nicht tot. Gerade wegen IDE. Heute läuft ja praktisch alles auf IDE mittels verkapselter SCSI Befehle (ausser du hast tatsächlich noch Programme, die mit der CHS Adressierung arbeiten ).

PS: Nicht, dass du mich falsch verstehst. Mittelfristig halte ich den SCSI Bus für ziemlich tot. Deswegen halte ich IDE aber noch lange nicht für der Weisheit letzter Schluss.

Theoretisch ja. Praktisch sieht es bei Harddiskzugriffen so aus, dass die gesamte Maschine geduldig auf die Daten wartet. Zumindest bei den aktuellen OS'en auf x86-er Basis.

Der Grund ist ein Relikt aus noch nicht all zu lange vergangenen Zeiten. Der alte ISA DMA Kontroller erlaubte obige vorgehensweise IIRC nämlich nicht. Und da alle heutigen OSe immer noch auf 386-er Code basieren (ja, auch Linux, ja, auch WinXP)...

Ich hatte mal eine IDE-Platte, die Müll auf den Bus ausgab. War kein Spass. Hat mir das gesamte System eingefroren. Nicht, dass dies mit SCSI nicht auch passieren könnte, versteht sich. Das ist ein Problem der PC Architektur.

Persönlich bin ich ja auf die internen Firewire Harddisks gespannt. IMHO umgeht Firewire geschickt die Probleme von IDE (maximal 2 Disks pro Bus, relativ hohe Prozessorlast) und von SCSI (meist umständliche Verkabelung, ca. ein Dutzend Standards). Jetzt müssen nur noch die Disks dahinter stimmen. ;-)

Ummm... In punkto BIOS gebe ich dir recht. Bis dato können die nicht von Firewire booten. Alles andere ist aber heute schon vorhanden, und zum Teil sogar in Serie. S-ATA muss sich erst noch bewähren. Ausserdem hat Firewire den Vorteil der höheren Universalität und Ausbaubarkeit.

S-ATA hat eigentlich nur einen Vorteil: In Serie wird der S-ATA Chip vermutlich ein paar Rappen billiger pro Stück, als der Firewire Chip. Leider könnte das unter Umständen schon reichen...

Ich verstehe nicht, wieso es zu der Frage "IDE oder SCSI" die Antworten "CDRW" und "DVDRW" gibt. "Floppy" kann man ja noch als Bus lesen. Und beim Raffzahndrive weiß ich nicht, was für einen Bus das braucht. (Wahrscheinlich einen Omnibus, weil es ja alles schluckt. ;-).

IMHO wären Antworten wie die folgenden eher passend gewesen:

• USB
• IEEE 1394 / FireWire / i.Link
• Parallel-Port
• SCSI-Extern
• etc.

--
Where do I find the Any Key?