RAID - Treiber ?

RAID - Treiber ? (12 Beiträge, 81 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo,

ich muss hier mal eine DAU-Frage loswerden, die mir noch niemand so richtig beantwortet hat:

Warum braucht man für einen (Hardware-)Raid-Controller eigentlich spezielle Treiber unter Windows? Ist es nicht Sinn und Zweck solch eines Raid-Controllers, dass er die Tatsache, dass es sich um ein Raid handelt, vor dem Betriebssystem verbirgt und sich als ganz normaler Festplattencontroller ausgibt, für den man auch keine besonderen Treiber benötigt?

windows muss ja den controller irgendwie ansprechen und erm daten zuschicken.
genauso wie einen normalen ide controller oder was auch immer

I google, therefore I am
nico

Darauf will ich ja hinaus. Normale IDE-Controller funktionieren doch alle irgendwie gleich, so dass der Standardtreiber von Windows genügt. Warum kann sich der Raid-Controller nicht auch so verhalten?

weil der standardtreiber eben dafür nicht reicht
jedes gerät benötigt einen treiber damit er mit dem system kommunizieren kann

Der Standardtreiber reicht für die IDE-Controller auf sämtlichen Board, die ich je in den Händen hatte. Warum kann sich der Raid-Controller nicht einfach als normaler IDE-Controller ausgeben und sich auch so ansprechen lassen? Die Software auf dem Rechner soll doch gar nicht wissen, dass da ein Raid läuft.

vielleicht weil er eben kein normaler ide-controller ist...

JEDER ide controller hat eigene treiber von der herstellerfirma weil da einfach das optimalste enthalten ist.

ein standardtreiber kann NIEMALS die performance eines originaltreibers erreichen

I google, therefore I am
nico

Hi!

Ich versuche das kurz zu erläutern, muss jedoch dazusagen, dass ich mich auf dem Gebiet zwar informiert habe, aber jetzt nicht in der Treiberentwicklung tätig bin und daher nur mein Verständnis des von mir gelesenen wiedergeben kann.

Mal ganz grundsätzlich zu Windows-Treibern: sehr grob gesprochen ist deren einziger Zweck, die Kommunikation zwischen Betriebssystem und Gerät zu beschleunigen. Es würde prinzipiell auch ohne Treiber funktionieren, aber dann meist um ein Vielfaches langsamer.
Dem zugrunde liegen die beiden Modi, in denen eine CPU operieren kann: der Real- und der Protected Mode. Das genau zu erklären trau ich mir aber jetzt nicht zu, vielleicht findet sich aber jemand, der das kann.

Jetzt zu Deiner Frage an sich: Das was Du als "Standard-IDE" Treiber kennst ist nichts anderes als die Implementierung der Grundlegenden Befehle, die ein Standard-IDE-Controller können muss. Mit den Herstellertreibern werden dann sämtliche Funktionen angesprochen, die möglich sind.
Als Beispiel sei hier Windows 98 hergenommen: vor Installation der Busmaster-IDE Treiber sieht man die Harddisks als "Harddisk Type 47", nach der Installation scheint dort der Name auf.

Nimmst Du jetzt Geräte (egal welcher Art) her, die entweder von diesem Standard abweichen oder gar überhaupt nicht unterstützen, so bedarf es einer "Übersetzung" - und das macht dann der Treiber.

Der RAID-Controller muss das RAID nicht "verbergen" - Windows sieht das ohnehin nicht. Aber der Treiber wird benötigt, um den Controller anzusprechen, damit dieser seinerseits das RAID ansprechen kann.

Ich hoffe, das war einerseits verständlich und andererseits inhaltlich korrekt - wie immer bitte ich um Korrektur, falls ich irgendwo Schwachsinn geschrieben habe.

greetz

glockman

- Ich bin ein Geek und steh dazu -

This system is

Theoretisch könnte man also einen Raid-Controller bauen, der sich als ganz normaler IDE-Controller ausgibt.

Unter diesem Gesichtspunkt sind dann alle gegenwärtig erhältlichen Raid-Controller irgendwie "Murks".

Ich bemühe mich immer, Hardware zu kaufen, die entweder so weit genormt ist, dass man keine besonderen Treiber benötigt (IDE-Controller, serielle Modems, Monitore), oder so weit verbreitet ist, dass es einen Treiber im Lieferumfang von Windows gibt (Netzwerkkarten von Realtek, WLan-Karten von Lucent).

Alles Andere verkürzt die Haltbarkeit der Hardware nämlich ganz erheblich. Wenn es die nächste Windowsversion gibt, dauert er entweder Monate, bis der Hersteller neue Treiber entwickelt, oder es schert ihn überhaupt nicht (häufiger Fall, da fühlt man sich so richtig übers Ohr gehauen), oder die Klitsche ist schon dicht.

Und selbst wenn es für den jeweiligen Raid-Controller Treiber gibt, wer will schon bei der Windowsinstallation mit Disketten hantieren müssen? Wer hat noch ein Disketten-Laufwerk?

Theoretisch könnte man also einen Raid-Controller bauen, der sich als ganz normaler IDE-Controller ausgibt.

Auch ein RAID Controller ist im Prinzip nichts anderes als ein "normaler" IDE Controller, aber er hat eben einen erweiterten Funktionsumfang.

Den echten Grund, warum er nicht als "normaler" Controller erkannt und installiert wird, kann ich Dir aber leider auch nicht nennen; meine Vermutung geht allerdings in die Richtung, dass jeder Hersteller sein eigenes Süppchen kocht, und daher von einheitlichem Standard keine Rede mehr sein kann.

Alles Andere verkürzt die Haltbarkeit der Hardware nämlich ganz erheblich. Wenn es die nächste Windowsversion gibt, dauert er entweder Monate, bis der
Hersteller neue Treiber entwickelt, oder es schert ihn überhaupt nicht [...]

Kann ich nur bedingt verstehen; die Sache mit den Treibern mag zwar stimmen, aber imho muss man ja nicht gleich nach Erscheinen einer neuen Version diese auch verwenden. Außerdem werden Treiber zu älteren Geräten meist in neueren Versionen schon wieder mitgeliefert.

Wer hat noch ein Disketten-Laufwerk?

Ich. Pro Rechner eines, das schließt sogar den Laptop mit ein. Was kann Dir besseres passieren, als ein Gerät, das gänzlich ohne Treiber auskommt?
Bei all den tollen Neuerungen wie USB Stick und Windows-BIOS Flash Utility: nix geht über eine Diskette.

greetz

glockman

- Ich bin ein Geek und steh dazu -

This system is

Theoretisch könnte man also einen Raid-Controller bauen, der sich als ganz normaler IDE-Controller ausgibt.

Kannst du nicht...
Denn ein RAID-Controller bietet ja weit mehr Möglichkeiten als ein Standard-Controller... Irgendwie denke ich, daß du den Sinn von RAID net verstanden hast und daher dein Verständnisproblem kommt...

Trennen wir mal in 1 - Bootvorgang:
Natürlich kann der RAID-Controller (das was ein Vorposter als langsam und treiberlos meinte) ganz normal die logischen Drives via int80h, int81h, ... zur Verfügung stellen. Das muß ja auch so sein, da er sonst das OS (das u.a. einen Festplattentreiber hat) net laden könnte - oder nur von Floppy

. Insofern verhalten sich RAID-Controller also genau so wie du willst.

und 2 - Betrieb:
Windows bietet "One size fits all"-Treiber für IDE-Controller. Das ist zwar an sich eine super-Idee - nur darf das immer nur der Plan B sein. Es gibt genug Buggy-Controller (extern und onboard) - auch von Marktführern. Das funktioniert dann so, daß man in den Treiber Bugfixes einbaut. Das sieht dann so aus: Bei Controller A ist bekannt, daß man net X und dann gleich Y machen darf - weil man sonst Daten verlieren kann. Also machen wir zwischen X und Y was sinnloses ohne Schaden - das möglichst schnell ist und wenig Zeit kostet. Bei Controller B hingegen wissen wir, daß man Z net machen darf, sondern Z durch Umwege realisieren muß - also verzichten wir auf Z, ...
Das bedeutet im Endeffekt, daß die generischen Treiber wirklich alle Workarounds von allen bekannten Bugs beinhalten - und dadurch oft massiv langsamer sind als optimierte Treiber, die u.a. nur die "eigenen" Bugfixes enthalten. Das Protected/Realmode-reinwerfen vom Vorposter war übrigens Unsinn. Natürlich gibt's im Protected mode keine Bios-Calls (denn das Bios ist eben Real-Mode) - es wäre aber natürlich weiterhin möglich, die interrupt-Zugriffe im Protected mode nachzubauen. Nur sind die noch _WEIT_ langsamer als die ganzen Workarounds in den generischen Treibern.

und 3 - RAID-Besonderheiten.
Mal angenommen, es handelt sich um einen Controller, der zumindest auch RAID1 oder RAID5 kann (IMHO tun das alle). Dann reicht es eben nicht, daß das System bei einem Plattenausfall weiterarbeitet (der bleibt ja eben transparent für das System) - weil dann hättest ja nix gewonnen. Irgendwann wird die 2. Platte auch sterben und dann hast erst den Scherben auf. Ziel ist daher, daß das Betriebssystem via Driver vom Controller _SOFORT_ informiert wird - damit du eben die defekte Platte tauscht, bevor noch was passiert. Das ist aber eben nicht Standard-IDE... Daher eigener Treiber.
Wenn du dann brav die defekte Platte in Betrieb getauscht hast - willst ja auch net neu ins Bios booten müssen um die Platte zu Konfigurieren - sondern dein System soll ja weiterlaufen. Also muß eine Applikation im System laufen können, die dem Controller mitteilt, was er mit der neuen platte tun soll - resyncen, ... -

prinzipiell ist es bei raid-controllern auch noch so dass gewissen funktionen garnicht in der hardware selber implementiert wurden, sondern diese eben vom betriebssystem ausgeführt werden müssen.
deshlab ist bei vielen raid-controllern auch die cpu-last beim zugriff auf das array höher als bei ner normal angeschlossenen festplatte. und da sehr viel weniger raid-controller eingesetzt werden als normale ide-controller schenken sich die meisten betriebssysteme deren einbindung ohne treiber.
und wie schon andere erklärt haben gibt es bei raid-controllern sehr viel mehr funktionen als bei einem normalen controller, deshalb wäre es etwas mühsam diese für jeden oder auch nur die gebräuchlichsten gleich ins os einzubeinden.
wobei das eigentlich nur für windows gilt, bin kein linux-experte, aber soweit ich weiß sind im linux-kernel schon sehr viele treiber von haus aus eingebunden (nur dass dummerweise der für meinen silicon image s-ata-controller 3112 nicht funktioniert so wie er soll und ich deshalb meine versuche mit linux noch vor der installation abbrechen musste *g*)

"Die größten Ereignisse - das sind nicht unsere lautesten, sondern unsere stillsten Stunden"
"Friedrich Nietzsche, Also sprach Zarathustra"

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung