Diskussion:RAID/Archiv/1

Dieses Diskussionsarchiv hat die empfohlene SeitengröVorlage:SSe erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite. Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise [[Diskussion:RAID/Archiv/1#Abschnittsüberschrift]] oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia https://de.wikiup.org/wiki/Diskussion:RAID/Archiv/1#Abschnittsüberschrift

- 2005 -

JBOD

Hallo, endlich konnte ich auch mal etwas zur Wikipedia beitragen: Ich habe hier das JBOD mit eingefügt (in der englischen Version steht es auch bei RAID, obwohl es eigentlich nur ein "AID" ist). Würde mich über Feedback freuen.

Gruß Steve

Ist das das gleiche wie "linear Raid"? So wird es meines Wissens nach von Linux genannt. Wäre eine interessante Ergänzung.

Hallo, JBOD ist das einfache zur Verfügung stellen jeden Laufwerks als eigenständige Volume also ohne Bündelung. Was Du beschrieben hast wird eigentlich als NRAID bezeichnet!

Gruß Knut

Guten Tag Knut,

dann würde ich deine Aufmerksamkeit bitte mal auf folgende Quelle hinweisen: http://www.zdnet.de/enterprise/server/0,39023275,39119381-6,00.htm Kollege und ich diskutieren auch schon die ganze Zeit, was was ist.

Gruß, Senbei

Der Begriff wird offenbar verschieden verwendet. "Just a Bunch of Disks" ist direkt übersetzt eben nur ein Bündel Platten - wie sie vom OS gesehen werden, ist eigentlch nicht definiert. Einige Hersteller von Hardware RAID Controllern bezeichnen damit jedenfalls eine Betriebsart, in der die einzelnen Platten dem OS als einzelne Platten präsentiert werden. Das wird auch in Testberichten zum Teil so bezeichnet. JBOD als "linear RAID", also mehrere Platten, die dem OS als eine präsentiert werden, ist wohl auch gebräuchlich und die zdnet Definition läuft darauf hinaus. Allerdings müsste es dann eigentlich JBODAO oder so heißen (As One). (Lineares Zusammenfügen von Platten ist allerdings in der Praxis wohl recht bescheuert... warum dann nicht Striping... aber naja.)

Unsinnig ist jedenfalls die derzeitige Behauptung im Artikel, bei Ausfall einer Platte bei linearem Zusammenfügen wären nur die Daten der jeweiligen Platte weg. Das dürfte je nach verwendeten Dateisystemen nur selten zutreffen. Daher korrigiere ich DAS jetzt schon mal.

Weiteres Know-How und Meinungen? Kruemelmo 22:51, 6. Aug 2005 (CEST)

Tests

Hallo, ich beschäftige mich grade ausführlich mit dem Thema RAID und habe in diesem Zusammenhang einige Tests durchgeführt. Ich wollte testen ob an dem "Gerücht" etwas dran is, dass JBOD linear beschrieben wird und im Falle eines Festplattenausfall die Daten der Anderen festplatte(n) noch nutzbar sind. => nach meinem Tests ist dem nicht so. Somit stellt sich die frage wo der Unterschied zu einem Stripeset liegen. Zu vermuten ist das die Daten wirklich erst nur auf eine Platte und bei zunehmender Fülle später aus die 2 Platte geschrieben werden (bsp. 123 456) und nicht wie beim Stripe immer Abwechselnd (bsp. 135 246) Gruß, Oliver 12:00, 10. Dez 2005

Also wenn ich einem JBOD eine neue Festplatte hinzufuege, existieren die alten daten weiterhin, und es ist halt der neu hinzugekommende Speicherplatz frei. Die Festplatten werden auch bei benchmarks huebsch nacheinander durchgegangen. Also Striping ist da nicht.

Also JBOD sind einfach irgendwelche Platten. Das kann ATA, SCSI oder was auch immer sein. Dann gibt es zu der Platte ein device ... Controller 0 Platte 0 zum Beispiel. Das isssssses. in der Regel haben die Controller keine RAID Intelligenz. W"as jetzt das OS mit den Platten macht ist egal. Mann kann das Stripen, Spiegeln oder Paritätisch absichern. Theoretisch könnte ein volume manager dann eine ATA uns eine SCSI Platte spiegeln.

Ciao - Stefan --Nzlwf8 20:46, 10. Dez 2005 (CET)

Bei einem JBOD-Ausfall können die Daten zwar vielleicht nicht unmittelbar weiterverwendet werden, auf jeden Fall können sie aber problemlos wiederhergestellt werden (außer die der kaputten Platte natürlich, die sind futsch). Außerdem ist der Vorteil von JBOD, dass sich beliebige Kapazitäten miteinander voll ausnutzen lassen, was bei den gängigen RAIDs nicht der Fall ist. Vom Wortlaut her ist zwar nicht definiert, dass sich diese Betriebsform dem OS als ein einziges logisches Laufwerk präsentiert, aber in der Regel wird das so gehandhabt. Obeliks 21:48, 20. Apr 2006 (CEST)

raid 1 ist lesend schneller als nur normal

Beim Lesen ist RAID 1 zumindest schneller als eine einzelne Festplatte, da der Controller die Daten von der Festplatte holt, die zuerst liefert.

Was aber rein rechnerisch zu vernachlässigen ist, da davon ausgegangen werden muß, daß beide Platten gleich schnell schreiben und lesen. mfg, --strangemeister@work 09:03, 24. Mär 2005 (CET)

Hmm... Also wenn man sich schon die Mühe macht, von allen Disks eines RAID1 Verbundes denselben Datenbereich zu lesen, dann will man die auch erst vergleichen, so dass also die langsamste Disk ausschlaggebend sein dürfte. In der Tat wird man wohl oftmals in demselben System oftmals nur gleichschnelle Disks finden, so dass sich diese Frage nicht richtig stellt... --213.54.77.217 17:02, 24. Sep 2006 (CEST)

Ist es nicht so, das bei einen RAID 1 das Lesen wesentlich schneller ist -> es wird gleichzeitig gelesen -> wenn erster Block von 1. Platte gelesen wird, kann schon der zweite Block von der 2. Platte angefordert werden... -- MasterLR 22:39, 26. Apr 2005 (CEST)

In der Tat. Wenn ich ein RAID Controller wäre, würde ich es so machen. Kruemelmo 14:32, 15. Jun 2005 (CEST)

Ich auch! ;-) Außer eben, wenn man es ganz genau nimmt... Dann könnte man von allen Disks des Verbundes lesen und dann hübsch vergleich, bevor man das Ergebnis weiterleitet. Ansonsten hat RAID1 ähnliche Vorteile beim Lesen wie RAID0, bloß dass eben etwas höhere Seek-Zeit beim sequentiellen Zugriff hinzukommen. Aber man kann in vielen Fällen ganz herrlich n (n=Anzahl der Disks im Verbund) konkurrierende lesende Zugriffe abwickeln, als wär man allein... :-) --213.54.77.217 17:02, 24. Sep 2006 (CEST)

Übrigens kann RAID 1 auch nicht beim Schreiben schneller sein... wenn man mal drüber nachdenkt. Die Aufgabe, Daten auf 2 Festplatten zu schreiben, ist in jedem Fall mehr, als nur auf eine, nicht wahr? Wer weiß es besser? Stimmt folgendes:

RAID 1 bietet eine erhöhte Performance beim Lesen, weil parallel von zwei Festplatten Daten angefordert werden können. Beim Schreiben gibt es keinen Performance Vorteil gegenüber einer einzelnen Festplatte.? Kruemelmo 10:36, 21. Jun 2005 (CEST)

von beiden platten gleichzeitig lesen geht nicht immer - muss von der software vorgegeben sein (softwareraid) oder der controller unterstützen - die promise light controller koennen das zb nicht - das darf man nicht verpauschalieren! --suit Benutzer Diskussion:Suit 18:47, 13. Jul 2005 (CEST)

hallo hat jemand schonmal was von sync-on-close gehört und daß ein write bei einigen schreiboperationen erst als fertig an das OS gemeldet wird, wenn die daten auf beiden platten stehen? bzw. den zusatzlichen overhead der spiegelung, die bei schlechten systemen 20% der schreibperformance kostet. geschweige denn die abhängigkeit vom filesystem... Nzlwf8 20:41, 1. Dez 2005 (CET)

Unter dem Namen nicht. Aber sicherlich ist es vernünftig zu warten, bis alle Festplatten das Schreiben bestätigt haben (zumeist also nur die Aufnahme in den Festplatten-Write-Cache). Das ist auch ganz Zeit-neutral, weil heutzutage im UDMA/SATA/SCSI Zeitalter gar kein erheblicher Zeitverzug durch das Erteilen von entsprechenden Anweisungen mehr entsteht. Heutzutage sollte also das Schreiben auf ein RAID1 (auch wenn es ein Software-RAID1 ist) ebenso schnell sein wie ohne RAID auf eine einzelne gleichwertige Festplatte... --213.54.77.217 17:02, 24. Sep 2006 (CEST)

Lesen von zwei Platten im RAID1 siehe RAID1.5. Keine Überragenden Vorteile, weil das Betriebssystem schon den nächsten Sektor anfordern müsste, der von der zweiten Platte gelesen werden soll. Wird die gleiche Datei mit beiden Platten gelesen sorgt der Pre-Fetch dafür, das beide Platte ohnehin den nächsten Sektor auf der Platte lesen. Steht der nächste Sektor "ganz woanders" auf der Disk, müssen zwei Platten zur neuen Stelle "seeken". Und das auch noch nacheinander, weil ja die zweite Platte erst den übernächsten Sektor" von der neuen Stelle lesen soll.

RAID0 liest auf zwei Platten "denselben" Festplattensektor mit jeweils halber Größe und setzt die Sektoren dann zusammen. Der Pre-Fetch der Festplatten liest dann schon jeweils die nächste Hälfte des neuen Sektor und beide Platten (hoffentlich gleich schnell) führen Seeks zu selebn Zeit aus.

RAID1 Leseoperationsbeschleunigung würde (meiner Meinung nach) nur durch NCQ/TCQ Sinn ergeben. RAID1 Sicher=beide Lesen dasselbe und Abgleich der Daten. RAID1 "Schnell" durch NCQ Unterstützung, das beide Festplatten beim Lesen zwei unterschiedliche Anforderungen an unterschiedlichen Stellen auf der Festplatte erledigen können. Dann würde der Aufwand des Kopfwechsels reduziert werden - dies ist eine erhebliche Zeit beim Lesen der Daten. (Seek Zeit / Lesezeit -> Glaubwürdigkeit der Seite kann ich nicht beurteilen. Scheint haber keine Werbeseite, sondern eine besprechende Seite zu sein. Graphik service time im Bereich Limitations of the PCI Bus -> http://www.storagereview.com/articles/200406/20040625TCQ_1.html)

Ob es ein RAID1 Controller mit NCQ/TCQ gibt würde mich interessieren. (Nicht nur NCQ zwischen Controller und Platte, sondern NCQ zwischen Rechner und Controller.). --Halifir 00:26, 26. Mai 2007 (CEST)

Also das möchte ich nicht so ganz unkommentiert stehen lassen: Es wird nicht "ein halber Sektor" gelesen, sondern immer ein oder mehrere (zusammenhängende) Sektoren eines Blocks (auch Stripe genannt), der durchaus zum Beispiel 128KB groß sein kann. Desweiteren ist ja nicht unbedingt nur ein Programm an den Festplatten-Daten interessiert sondern vielleicht auch mal 2 oder 3, so dass man ganz leicht sehen kann, dass auch ohne Read-Ahead ein Performance Vorteil entsteht (bei RAID0 und RAID1 und RAID5 jedenfalls - außer bei RAID0 und RAID5, wenn die Programme alle Pech haben und zufällig alle Blöcke lesen, die auf derselben Disk (und eben nur da anders als bei RAID1) stehen). --89.53.33.247 13:49, 19. Jun. 2007 (CEST)

Richtig. Halber Festplattensektor war Unsinn. Halber logischer Betriebssystem Block war gemeint, der kann sich aus vielen Sektoren zusammensetzen. -- Halifir 19:28, 25. Jun. 2007 (CEST)

Auf Betriebssystemebene, z.B. bei mir in einigen Versionen der Linux Softwareraid md Tools für RAID-1 oder RAID-10, gibt es eine read balancing Routine, die die Platte wählt, deren Schreiblesekopf näher am Ziel liegt oder diejenige mit der kürzeren Lesequeue (siehe /usr/src/kernel/drivers/md/raid*.c). -- Halifir 19:28, 25. Jun. 2007 (CEST)

Was passiert wenn der Controller auf beiden Platten unterschiedliche Daten finden? (durch defekte Sektoren oder fehler beim Schreiben) Korrektur gibt es ja keine. Entscheidet der Controller dann selbst welches er nimmt? Bekommt der Controller das überhaupt mit?

Anders als beim RAID2 ist man beim RAID1 darauf angewiesen, dass die Festplatten selbst fehlerhafte Daten erkennen (hierzu wird heutzutage wohl eine Prüfzahl (CRC) gebildet und gespeichert; wenn diese Zahl nicht zu den Daten passt, wird dies als Fehler gewertet). Nur so kann man falsche von richtigen RAID1 Daten unterscheiden und nur so kann man dann im Fehlerfall einen erneuten Leseversuch von einer der "überlebenden" Festplatten (hoffentlich mehr als 0 (in Worten: Null)) anordnen. --213.54.77.217 17:02, 24. Sep 2006 (CEST)

Disk-Array Typen

Hat schon mal jemand etwas von Disk-Array Typen gehört? Drei Typen werden unterschieden:

+ Fully Synchronous Array

 - Seek und Rotation sind synchronisiert (Systolisches Array – Synchrone Taktung und Steuerung)

+ Partially Synchronous Array

 - Seek ist synchronisiert, aber die Rotation ist unabhängig (Software Fully Synchronous Array)

+ Fully Asynchronous Array

 - Seek und Rotation sind unabhängig voneinander (Random Zugriffe)

Weshalb ein RAID1/10 "schneller" beim Lesen im Random-Mode ist, wird dadurch bestimmt, dass die Wahrscheinlichkeit eines Zugriffs auf einen Daten-Block bei einer Spiegelung (2 Disks) um 33% steigt. Für die Disk-Array Typen gibt es eine allgemeine Gleichung, wo man das Ganze nachrechnen kann. Beim sequentiellen Lesen ist ein RAID1/10 ca. 15% "schneller". Hingegen beim Schreiben im Random-Mode auf RAID1/10, ist die Wahrscheinlichkeit eines Zugriffs auf zwei Daten-Blöcke um 33% geringer, weil Seek und Rotation nicht synchron arbeiten. Wer sich mit dem Thema RAID auseinandersetzt, müsste erst mal die Inter-/Intra I/O-Parallelität beschreiben, um Aussagen über irgendwelche Lese-/Schreib-Vorgänge zu treffen.

+ Inter I/O-Parallelität = Auftragsparallelität (Random Zugriffe)

 - MEHRERE Aufträge verteilen sich gleichzeitig auf MEHRERE Platten

+ Intra I/O-Parallelität = Zugriffsparallelität (Sequentielle Zugriffe)

 - EIN Auftrag benutzt MEHRERE Platten

Beantworten Sie sich mal folgende Frage: Wie viele parallele Lese-/Schreib-Zugriffe kann man z.B. bei einem RAID5(6+P) und bei einem RAID10(6+6) rein statistisch durchführen?

mfg. W. Kinder

RAID 5

Bei RAID 5 wird mehrmals von Redundanz geschrieben. IMHO ist R5 aber nur Striping mit Parität. vllt. kann das ja mal jemand überarbeiten, der von RAID mehr ahnung hat. --pixelFire (!?*) 13:06, 18. Apr 2005 (CEST)

Man kann die Parität auch als Redundanz verstehen -> es liegen "doppelt" Daten vor... bei einer Parität muss man nur die eigentlichen (verlorenen) Daten errechnen, im Gegensatz zur Redundanz in einen RAID 0 ;-) -- MasterLR 22:31, 26. Apr 2005 (CEST)

@MasterL: Ich denke mal das du nicht Raif 0 Null, sondern Raid 1 meintest, denn in einem Raid 0 System liegt weder eine Redundanz, noch eine Parität vor Gruß Dapor

Parität ist meiner Meinung nach aber nicht gleich Redundanz. Aus der Parität kann man schließen, ob die Daten noch korrekt vorliegen. Fällt aber eine gesamte Platte aus, so müssen die Daten rekonstruiert werden. Dies ist aber allein mit Hilfe der Parität nicht möglich. Falls ich da falsch liege wäre es gut, wenn jemand, der sich damit auskennt, noch einen kleinen Hinweis einfügt, wie dies funktioniert. -- boente 14:29, 03. Aug 2005 (CEST)

Bei RAID 5 werden die Parity-Informationen über eine XOR-Verknüpfung gebildet. Die Parity-Informationen sind somit redundant, siehe Redundanz (Information). Bei einem Plattenausfall hat man quasi eine Gleichung mit einer Unbekannten und kann die Daten der ausgefallenen Platte wieder errechnen. Bei einem RAID 5 mit nur 2 Platten würden die Daten doppelt vorliegen, ansonsten nicht (n+1). Bei RAID 0 gibt es keine Redundanz. Mckuno 14:23, 9. Aug 2005 (CEST)

Yep, das ergibt ein klares Bild. Danke für die kleine Hilfestellung :-) -- boente 14:40, 10. Aug 2005 (CEST)

Ich habe auch noch eine Frage zur Kapazität von RAID 5. Wohl stimmt es, dass man bei jedem RAID-Level gleiche Platten/Partitionierungen verwenden sollte. Hier wird die Formel s*(n-1) angegeben, die z.B. auch im Linux-Software-RAID-Howto angegeben wird. Ist es aber nicht so, dass der Kapazitäts"verlust" geringer wird, je mehr Platten ich für RAID-5 verwende, da ja die Paritätsinformationen über meinen Verbund aufgeteilt werden? Also, wenn ich 4 Platten verwende, habe ich 25% Verlust, bei 5 Platten nur mehr 20% (Formel: Overhead=100/n in Prozent).

Bitte um Klärung. lg --Subaqua 10:12, 3. Aug 2006 (CEST)

Ja und? Wo ist da der Widerspruch? (nehme wir mal identische Platten), s sei 50 GB (rechnet sich sehr einfach).

1. 3 Platten à 50 GB = 150 (netto): Gesamtnutzkapazität = s(n-1) = 50(3-1) = 50*2 = 100; 150 - 100 ist Verlust 50 GB = 33%
2. 4 Platten à 50 GB = 200 (netto): Gesamtnutzkapazität = s(n-1) = 50(4-1) = 50*3 = 150; 200 - 150 ist Verlust 50 GB = 25%
3. 5 Platten à 50 GB = 250 (netto): Gesamtnutzkapazität = s(n-1) = 50(5-1) = 50*4 = 200; 250 - 200 ist Verlust 50 GB = 20%
   

Wo ist dein Problem? --WikiMax 10:26, 3. Aug 2006 (CEST)

Kein Problem, wollte wissen, ob das auch wirklich so _ist_, bzw. hab ich auch festgestellt, dass die andere Rechnung nur "hinten herum" geht :-) Hab aber noch eine Frage: Wäre es nicht theoretisch möglich, Festplatten/Partitionen verschiedener Grössen zu kombinieren _ohne_ Kapazitätsverlust? Sollte doch möglich sein, wenn es nur striping ist. Oder übersehe ich da etwas?

--Subaqua 15:23, 3. Aug 2006 (CEST)

(Offtopic: wenn du vor deinem Beitrag pro neue Zeile(!) jeweils einen Doppelpunkt mehr einträgst als dein Vorredner, wird durch Einrückung eine Antworthierarchie geschafen, die es (nach traditioneller Sicht) übersichtlicher macht - habe es für dich nachgetragen.
Wenn du wirklich mit vier Tilden ~ bzw. oben über dem Bearbeitungsfenster das zweite Ikon von Rechts - unterschreibst, wird Name, Link zu deiner Benutzer- und Diskussionsseite, sowie Datum und Uhrzeit automatisch eingetragen. Das Ikon bastelt auch noch die zwei Bindestriche/Minus-Zeichen davor. Offtopic-End)
Du übersiehst:

• Performance: nur wenn auf allen(!) Datenträgern gleichzeitig geschrieben bzw. gelesen werden kann, gibt es einen Geschwindigkeitsgewinn (oder zumindest keinen (noch größeren) Geschwindigkeitsverlust - je nach System). Müsste wegen unterschiedlicher Größe (z.Bsp. HD2 ist voll) immer nacheinander Geschrieben werden, wäre dies ein riesiger Performanceverlust. Als Beispiel würde RAID5 mit 4 HDDs zu RAID5 mit 3 HDDS wechseln und RAID5 mit 3 HDDs würde zu RAID1 wechseln, wenn jeweils eine Platte voll wäre. Müsste/sollte berechnet werden, dass Daten anteilsmäßig nach der Größe der Partition/HD verteilt werden, wäre dies eine enorme Rechenaufgaben mit enormem Geschwindigkeitsverlust.
• Gleiches gilt noch einmal für die Paritätsdaten, diese müssten dann quasi auch noch einmal höchst komplex berechnet und geschrieben werden.
• Prinzipiell ist die Parität der Grund für den Netto-Kapazitätsverlust bei identischgroßen HDDs (aber dies war dir wohl schon bewusst und nicht Inhalt deiner Frage).

--WikiMax 16:22, 3. Aug 2006 (CEST)

Enthält der Artikel zu Raid 5 nicht einen entscheidenden Fehler? Warum sollte der Durchsatz beim Schreiben im Vergleich zu Raid 0 schlechter sein? Oder ist das Argument, dass man heutzutage keinen Controller bauen kann, der in der Lage ist praktisch ohne Zeitverlust die Parity zu berechnen? Einfache Milchmädchenrechnung: Annahme: Schreiben von 1024 Byte auf eine Platte: 1 Zeiteinheit. Schreiben von 512 Byte auf eine Platte: 0,5 Zeiteinheiten. Rechnung: Schreiben von 1024 Byte auf Raid 5 mit drei Platten: 512 Byte Daten, Platte 1, 0,5 Zeiteinheiten; 512 Byte Daten, Platte 2, 0,5 Zeiteinheiten; 512 Byte Parity, Platte 3, 0,5 Zeiteinheiten; Gesamtdauer: 0,5 Zeiteinheiten. Also exakt die Zeit welche man auch bei einem Raid 0 erwarten dürfte. Kann das mal jemand erklären? -- BoMbY 18:00, 30. Mai 2007 (CEST)

raid5 enthält einen etwas höheren protokollaufwand damit das berechnen des xor transparent abläuft. der unterschied ist heutzutage nur noch theoreticsher natur, in benchmarks lässt er sich statistisch bei guten controllern kaum noch nachweisen. die schreibvorgänge für die einzelnen blöcke werden hintereinander abgeschickt, so dass für r0 zwei und für r5 drei vorgänge nötig sind. ist der controller zu langsam so wird dies merklich, moderne gute controller schicken diese anfragen aber wesentlich schneller ab, als die platten hinterherkommen, so merkt man das nicht.

Der Aufwand ist nicht nur theoretischer Natur (weil XOR so schnell geworden ist). Es gibt einen prinzipbedingten Unterschied zu RAID0, der im zweiphasigen Schreibverfahren liegt, wenn die Datenmenge nicht exakt die Chunk-Size Größe hat. Bezügliche der Annahme ist also 1024 die Chunk-Size und 512 die Stripe-Size. Werden jetzt nur die ersten 512 Byte geschrieben muss die Parität aber für den gesamten Chunk berechnet werden. Bei einem typischen 3 Platten RAID5 ergibt sich erst ein Lesen der zweiten Hälfte des Chunk (ein Stripe) von der zweiten Daten Platten (Zeiteinheit 0,5 vor dem Schreiben der Parität), dann erst Berechnen der neuen Parität und Schreiben der neuen Parität (Zeiteinheit 0,5). Da das Lesen der zweiten Hälfte der Daten und das Schreiben der Parität nicht zeitgleich erfolgen kann, ergibt sich anstelle der Summe der Zeiteinheiten von 0,5 dann eine 1,0. Ob das Schreiben der neuen Daten parallel zum Lesen von der zweiten Datenplatte oder parallen zum Schreiben der Parität erfolgt hat dann keinen Einfluss auf die Gesamtzeit. Sind die zu ändernden Daten noch kleiner als die Stripe-Size müssen von zwei Platten die Ursprungsdaten gelesen werden. Neue Daten in Chunk im Speicher einfügen, dann Parity berechnen und alles wieder auf auf alle Platten schreiben. Im Beispiel wieder zwei sequentielle Operationen, also Zeiteinheit von 1.0. (Dann kommt noch das Berechnen der XOR Parität hinzu. Ein kleiner, aber in der Summe nicht komplett zu vernachlässigender Zeitfaktor, währenddessen der Cache des RAID Controllers belegt ist.)

Im Artikel wird ja aber ohnehin genau darauf verwiesen: "In schreibintensiven Umgebungen mit kleinen, nicht zusammenhängenden Änderungen ist RAID 5 nicht zu empfehlen, da bei zufälligen Schreibzugriffen der Durchsatz aufgrund des zweiphasigen Schreibverfahrens deutlich abnimmt." Halifir 16:41, 7. Aug. 2008 (CEST)

Für den Preis eines RAID5-Controllers mit drei Platten ist meistens bereits eine vierte Festplatte für ein (höherperformantes) RAID 10 zu bekommen. Das ist meines erachtens heutzutage überholt, ein gutes mainboard für ~150€ hat schon heutzutage öfters einen raid5 controll onboard (z.b. nforce 590 sli chipsätze)

dem kann ich nur zustimmen.. das sollte geändert werden 85.177.142.236 01:12, 24. Mai 2008 (CEST)

World of Warcraft

Sollte das nicht in einen etra artikel aufgespalten werden (weil das hat ja nun wirklich nix mit Massenspeichern zu tun... -- nomike 11:09, 09. Mai 2005 (CEST)

Das sollte überhaupt nicht in Wikipedia erwähnt werden. Wir sind eine Enzyklopädie und kein Lexikon für die Spezialterminologie irgendwelcher Computerspiele. So wie ich das sehe ist Raid in diesem Fall nur ein anderer Begriff für Clan, Gilde oder was weiß ich welches Wort gerade wieder schick ist für Zusammenschlüsse von Spielern. Weißt Du wo die Raid-Sache hingehört? In den Artikel World of Warcraft, und nirgendwo sonst. --Echoray 12:06, 9. Mai 2005 (CEST)

Aber Wikipedia ist ein Lexikon für die Spezialterminologie irgendwelcher Computeradapter? Ich bitte dich. Wenn du schon Spezialwissen gut heißt, dann bitte *alles* Spezialwissen. Und Raid bzw. Raid-Gilden sind ein Online-Spiel Phänomen, das gibts seit Everquest - und wenn wer davon hört und sich fragt was das ist, warum soll er das nicht auf wpedia nachschlagen dürfen?

Wie wäre es mit Vorlage:Dieser Artikel? --Flominator 02:03, 16. Jun 2005 (CEST)

Kleine Anmerkung dazu: Der Raid in einem Online-Spiel (nicht nur World-of-Warcraft) ist mit der ursprünglichen Definition von Raid vergleichbar. Ich finde, er brauch demnach gar nicht separat erwähnt werden. -- Zefrian 19:46, 24. Jun 2005 (CEST)

Da ist was dran. Man sollte Raid aber noch ein wenig in Richtung Computerspiele ausbauen! --Flominator 23:59, 24. Jun 2005 (CEST)

damit sollte jetzt schluss sein, hab Raid (Computerspiel) und Raid (Begriffsklärung) erstellt --suit Benutzer Diskussion:Suit 11:37, 31. Aug 2005 (CEST)

RAID 10 vs. RAID 01

Verstehe ich das so richtig?

Angenommen ich habe vier gleichgroße Platten: A,B,C,D

RAID 10 ist ein Raid-0-Array über Raid-1-Arrays, also R0( R1(A,B) , R1(C,D) ) Wenn A+B oder C+D ausfallen, sind meine Daten weg, wenn nur eine Platte ausfällt oder eine andere Kombination von zweien, sind meine Daten noch da.

RAID 01 ist ein Raid-1-Array über Raid-0-Arrays, also R1( R0(A,B) , R0(C,D) ) Wenn A+C oder B+C oder A+D oder B+D ausfallen sind meine Daten weg, wenn nur eine Platte ausfällt oder eine andere Kombination von zweien, sind meine Daten noch da.

Ist die Chance eines Datenverlustes bei Raid 01 dann nicht etwa doppelt so hoch wie bei Raid 10? Wenn, dann sollte das im Artikel Erwähnung finden, aber ich bin mir halt nicht 100%ig sicher ob's stimmt.

-- Joern Heissler 2005-07-22 16:46

Sehe ich genauso, bei RAID 10 führen 2 von 6 möglichen Doppel-Disk-Ausfällen zum Komplettausfall, bei RAID 0+1 4 von 6. Einzeldiskausfälle stellen bei beiden Varianten kein Problem dar.

Mckuno 14:06, 9. Aug 2005 (CEST)

Hi, ich stimme euch zu. Man sollte auch die daraus entstehende Konsequenz im Auge behalten, dass nämlich bei einem Einzeldiskausfall die Restaurationszeiten völlig unterschiedlich sind. Ein RAID 1+0 ist ein Stripe-Set von Spiegeln - bei Ausfall einer einzelnen Platte muss nur diese Platte resynchronisert werden. Ein RAID 0+1 dagegen ist ein Spiegel von Stripe-Sets, was bedeutet, dass beim Ausfall einer einzelnen Disk alle Platten des Spiegels neu geschrieben werden müssen (weil dann auch die anderen Platten des Spiegels stale sind).

Vorteil von RAID 0+1: im Normalbetrieb schneller als RAID 1+0.

Vorteile von RAID 1+0: höhere Sicherheit gegen "Tod durch Double Disk Error" und kürzere Restaurationszeiten.

Gruß --Robertp 21:58, 9. Aug 2005 (CEST)

Ist 0+1 und 1+0 nicht mehr oder weniger identisch, vom Platteninhalt her? Wenn man mal kurz außen vor lässt, dass der Controller evtl. irgendwelche Kennungen auf die Platten schreibt, sollten doch beim 0+1 mit der Konfiguration R1( R0(A,B) , R0(C,D) ) die Platten A und B identisch sein, genauso die Platten C und D (logisch, ist ja gespiegelt). Beim 1+0 als R0( R1(A,B) , R1(C,D) ) ist doch R1(A,B) und R1(C,D) identisch, damit doch auch die Platten A und C sowie die Platten B und D. Wenn ich dann ein bisschen umkonfiguriere, müsste doch mit den Platten aus meinem 1+0 folgende Konfiguration möglich sein: R1( R0(A,C) , R0(B,D) ). In der Realität wird das möglicherweise daran scheitern, dass der Controller Kennungen auf die Platten schreibt und dann merkt, dass ich versuche, Platten aus zwei verschiedenen Arrays zu kombinieren...

Habe ich da jetzt was falsch verstanden? Würde meine Aussage nicht den Überlegungen zur Ausfallwahrscheinlichkeit beim Doppel-Crash widersprechen?

Grüße Mhier 17:30, 30. Mär 2006 (CEST)

Stimmt - Platteninhalt, Ausfallwarscheinlichkeit, Geschwindigkeit, etc. ist zwischen RAID 10 und RAID 0+1 vollkommen identisch. Das sollte man eigenlich an den Bildern bzw. der Zusammenfassung erkennen... Villeicht sollte man es im Text nochmals erwähnen. -- MovGP0 13:01, 20. Mai 2006 (CEST)

Damit ist dann doch auch die obige Diskussion hinfällig. oder? ;) Und damit wäre auch der letzte Absatz im Artikel unter RAID 10 falsch? Danke für die Antwort! -- Mhier 20:45, 30. Mai 2006 (CEST)

Tut mir leid aber die Ausfallwarscheinlichkeit zwischen 1+0 und 0+1 ist nur bei 4 platten identisch. Ab 6 Platten hat 1+0 die Nase vorn. Beispiel für 20 Platten: Raid 0+1: Ein satz mit 10 platten wird beschrieben und komplett gespiegelt. fällt eine platte aus block 1 aus, übernimmt block 2. jetzt muss nur noch eine platte aus block 2 ausfallen (egal welche) und beide blocks sind unbrauchbar. Wahrscheinlichkeit 9/10.

Raid 1+0: Ich hab 10 Plattenpaare a 2 platten. Fällt eine platte aus, muss exakt die Spiegelung der platte ausfallen damit mein System tot ist. Wahrscheinlichkeit 1/19 (nicht signierter Beitrag von 92.75.16.141 (Diskussion | Beiträge) 21:57, 9. Jul 2009 (CEST))

Auch wenn das Mathematisch "nicht ganz" stimmt hast du recht ;) --suit Benutzer Diskussion:Suit 12:34, 10. Jul. 2009 (CEST)

Controller / Realisierungsmöglichkeiten erwähnen?

Sollten die verschiedenen Möglichkeiten der Realisierung (Hardware- vs. SoftwareRaid, "Billig"-Raidcontroller = SoftwareRaid, SCSI/SATA/IDE-Raid etc.) erwähnt werden, oder gehört das von der Thematik nicht hier herein?

--MauriceM 20:02, 3. Aug 2005 (CEST)

Also ich würde mich darüber freuen. Schon allein weil nur wenige Leute das kleine, schmutzige Geheimnis der Computerindustrie in Sachen "Billig-Raidcontroller" kennen ;-) --Echoray 20:18, 3. Aug 2005 (CEST)

Einleitung & Externes Storage-Array

Hallo Flominator, du hattest mich gebeten, meine Veränderungen an der Einleitung zu kommentieren (übrigens danke für dein Feedback :-)

Die erste Veränderung war, dass ich in der Passage "oft fälschlicherweise auch für Redundant Array of Independent Disks gebräuchlich" (oder ähnlich) das Wort "fälschlicherweise" durch "alternativ" ersetzt habe.

Anscheinend mochtest du diese Veränderung nicht und hast sie wieder rückgängig gemacht. Die Frage ist hier, ob es falsch ist, den Buchstaben I als "independent" aufzulösen, oder ob es als eine sinnvolle Alternative zum historischen "inexpensive" gestattet werden darf.

Die zweite Veränderung war die Einführung des externen Storage-Arrays. Die könnte man anstatt in der Einleitung auch in der Rubrik Allgemein unterbringen. Das ist eine Frage der Organisation des Artikels.

Wie siehst du die beiden Punkte?

Gruß --Robertp 21:14 7. Aug 2005 (CEST)

Hallo Robert, danke für die Antwort. Das Storage-Array ist kein Problem. Mit dem I sieht es anders aus. Die Platten sind ja nie unabhängig, weil sie im Verbund arbeiten! --Flominator 22:28, 7. Aug 2005 (CEST)

Hi Flo, jede der Festplatten kann, herausgelöst aus dem RAID-Verbund, als eigenständige Disk fungieren. Den Unterschied bildet eigentlich nur der Rahmen der Platte, auf dem Chips angebracht sein können, die für ein spezielles Array (ob HW-RAID oder JBOD) zusätzliche Firmware-Informationen zur Verfügung stellen. Die Festplatte als solche (ohne Rahmen) kann in der Regel überall eingesetzt werden (so zum Beispiel als interne Disk / Boot-Disk für Unix-Hosts als auch in non-Unix-Systemen wie Windows-PCs). Gruß ;-) --Robertp 23:34 7. Aug 2005 (CEST)

herausgelöst aus dem RAID-Verbund Genau dort scheint der Knackpunkt zu liegen. Im Verbund sind die Platten meiner Meinung nach halt eben nicht unabhängig. Du allerdings argumentierst damit, dass es ein Verbund von unabhängigen Platten ist, die erst durch den Verbund die Unabhängigkeit verlieren. Ich weiss leider nicht, wie wir uns einigen sollen. --Flominator 11:10, 8. Aug 2005 (CEST)

Hallo Flo, ich denke, dass Kruemelmo diesen Punkt inzwischen toll gelöst hat durch eine unanfechtbare neue Formulierung. Gruß --Robertp 0:30 9. Aug 2005 (CEST)

Hi Flo (Florian?) - Sieht so aus, als sei die Einleitung dein Baby. Aber die Fassung von Kruemelmo zuvor gefällt mir ehrlich gesagt besser. Aus zwei Gründen. (1) Sie ist kürzer. Keiner, der einen Artikel über RAID nachschlägt, braucht Übersetzungshilfen vom Englischen ins Deutsche (außerdem ist mir etwas unwohl, wenn Array als Feld übersetzt wird). (2) Es gibt "Unworte", die Unbehagen beim Leser hervorrufen können - dazu gehören "fälschlicherweise" und "widerspricht". Bei einem auf Neutralität ausgerichteten Lexikon-Artikel sollte man diese vermeiden.

Bist du damit einverstanden, dass die alte Fassung wiederhergestellt wird? Aloha --Robertp 1:37 10. Aug 2005 (CEST)

Hi Robert, (ja, Florian), dass die Einleitung mein Baby ist, stimmt wohl. Ich halte es für keinen Fehler, dem Benutzer zu sagen, was die Begriffe auf deutsch überhaupt bedeuten. Zweitens stellt sich mir noch immer folgende Frage: Ist die neuere Übersetzung nur ein Marketing-Gag oder steckt da Sinn dahinter? Wenn es ein Marketing-Gag ist, sollte das auch erwähnt werden! --Flominator 14:42, 12. Aug 2005 (CEST)

Hi Florian, das Wort Array sollten wir besser übersetzen mit Anordnung oder Reihe, siehe LEO [[1]] (aber den Link kennst du wahrscheinlich schon). Zu der Frage, ob "independent" als salonfähig gilt oder als den Urhebern widersprechend, möchte ich folgendes sagen: der Begriff RAID mit "inexpensive" wurde 1987 geprägt. Das war in der "Pionierzeit" der Festplatten, in der 200 MB noch 10 kg gewogen haben. Heute gibt es keine "inexpensive" Disks mehr, weil alle Platten billig sind. Die Community der RAID-Nutzer hat im Verlauf der Evolution der Festplatten das "I" mehr und mehr als "independent" interpretiert (was ja im Prinzip auch schon 1987 richtig war). Ein "Marketing-Gag" ist das "independent" sicherlich nicht - aber möglicherweise war 1987 das Wort "inexpensive" ein Marketing-Argument, um eine Publikation in einem renommierten Journal unterzubringen. --Robertp 05:20, 13. Aug 2005 (CEST)

PS: Viel Erfolg bei deiner Kandidatur zum Wiki-Admin ;-)

Wenn du das oben im Artikel genauso begründest, wäre es für mich ok. Für dich dann auch?

Dankeschön!

--Flominator 16:32, 13. Aug 2005 (CEST)

Begriffsklärung - Redundant Array OF Independent/Inexpensive Disks

Der Begriff setzt sich eigentlich aus zwei Elementen zusammen.

1. WAS - Redundant Array of Data (or Array of Data and Redundancy)

2. WO - Independent/Inexpensive Disks

Wollte man "Redundant Array OF Independent Disks" einigermaßen richtig "übersetzen"

müsste man schreiben:

a) Redundantes Feld von Daten AUF unabhängigen Festplatten

b) Redundante Daten-Anordnung AUF unabhängigen Festplatten

Dahinter stehen zwei Orthogonale Konzepte - Data Striping and Redundancy.

Man kann DISKS auch durch DRIVES ersetzen, weil solche Redundanten Daten-Felder

auch auf andere Datenträger-Arten anwendbar sind z.B. Soild State Drive/Disk.

Gruß Woki (nicht signierter Beitrag von 89.60.241.244 (Diskussion | Beiträge) 17:21, 23. Aug. 2009 (CEST))

Änderungen

Hallo zusammen, ich bin beruflich eng mit dem Begriff RAID verbunden und würde gerne mehrere Aspekte hinzufügen sowie einige (wenige) Aussagen in diesem Artikel richtigstellen. Darf ich?

Gruß --Robertp 0:27 6. Aug 2005 (CEST)

Ja klar. Dazu musst Du nicht fragen. Mach einfach und sei mutig! Wenn jemand von berufswegen Ahnung von der Sache hat ist mir das übrigens auch tausendmal lieber als eine ganze Kompanie Menschen, die RAID nur von ihrem Zocker-Computer kennen... --Echoray 12:51, 6. Aug 2005 (CEST)

Danke für das Feedback und die Info, Echoray :-) Na dann werde ich mal loslegen ...

Gruß --Robertp 23:27 6. Aug 2005 (CEST)

Hallo Robertp, danke für deine Ergänzungen, ich habe noch mal einiges von dem, was du gemacht hast, weitergetrieben. Der Begriff "Volume Management Software" ist mir übrigens nicht ganz klar. Aus welcher Ecke kommt der? Ich bin vor allem in der Windows und Linux Welt tätig und habe mit kleineren Hard- und Software RAIDs zu tun, aber der Begriff ist mir noch nicht untergekommen. Gruß Kruemelmo 23:24, 8. Aug 2005 (CEST)

Hallo Kruemelmo (Krümelmonster?), deine Veränderungen gefallen mir ganz gut (obwohl ich noch nicht alle gelesen habe), sie machen den Text auf jeden Fall glatter. Du scheinst aktuell auf dem laufenden zu sein (denn du kennst Serial ATA). Auch schönen Dank dafür, dass du meinen ersten Beitrag zur Diskussion nach unten gestellt hast. Ich war mir anfangs garnicht sicher, wo er hingehört - bei email und blog fügt man die neuen Kommentare oben an. Jetzt weiss ich, wo der Konsens der Wikipedianer hin neigt - Ergänzungen nach unten. Gruß --Robertp 23:59 8. Aug 2005 (CEST)

PS: "Volume Management Software" ist am häufigsten der Veritas Volume Manager, der von SUN, HP und IBM (um mindestens drei zu nennen) bei deren Unix-Derivaten genutzt werden kann. Von SUN weiss ich, dass alternativ die Solstice Disk Suit als Volume Manager existiert. Bei dem Logical Volume Manager von IBM handelt es sich meines internen Wissens zufolge um einen lizensierten Veritas Volume Manager.

Oh, hier hast du mir ja auch geschrieben! Schön, dass meine Überarbeitung des Anfangs ankommt. :) Ich kann beitragen: In Linux Systemen heißt die Software RAID Software raidtools. Bei Windows heißt sie offenbar Festplattenmanager... Vielleicht wäre es am besten, diese konkreten Bezeichnungen draußen zu lassen? Gruß Kruemelmo 22:28, 9. Aug 2005 (CEST) (Kääksääh)

Hi Krümelmonster. Na klar lassen wir diese konkreten Bezeichnungen aus dem Artikel raus - sie erscheinen nur hier in der Diskussionsrunde. Es sollte ausreichen, im RAID-Hauptartikel ganz kurze Statements zu HW-Raid und SW-Raid zu treffen (so wie du es auch getan hast). Bei Bedarf könnte man (mit Linkverweisen) zwei neue Artikel namens Hardware-RAID und Software-RAID verfassen. Aloha --Robertp 23:10 9. Aug 2005 (CEST)

Anmerkung

Anmerkung - "Volume Management Software" ist am häufigsten der Veritas Volume Manager, der von SUN, HP und IBM (um mindestens drei zu nennen) bei deren Unix-Derivaten genutzt werden kann. Von SUN weiss ich, dass alternativ die Solstice Disk Suit als Volume Manager existiert. Bei dem Logical Volume Manager von IBM handelt es sich meines internen Wissens zufolge um einen lizensierten Veritas Volume Manager.

So ein Schwachsinn: Bei dem Logical Volume Manager von IBM handelt es sich meines internen Wissens zufolge um einen lizensierten Veritas Volume Manager.

Mit dem internen Wissen ist es nicht all so gut bestellt. Der AIX LVM war der erste Logical Volume Manager der bereits im BS integriert war. Den AIX LVM gibt es seit 1989. Danach kam Veritas und dann die restlichen Dinger.

Mfg. W. Kinder

Schon wieder JBOD

Sorry für die Belästigung, aber ich möchte nochmals intervenieren an dieser Stelle. Ein JBOD ist mir bekannt als ein Storage Array, welches keinen RAID-Controller besitzt. Die Festplatten werden dem Betriebssystem als einzelne Disks zur Verfügung gestellt. Input und Output werden transferiert durch einen Hardware-Baustein, der I/O-Modul genannt wird. Entweder wurde für das betreffende Array nie ein RAID-Controller entwickelt, oder der Käufer entscheidet sich, aus Gründen der Kostenersparnis, auf einen RAID-Controller zu verzichten. Im letztgenannten Fall ist das I/O-Modul erheblich preiswerter als der RAID-Controller. Best regards --Robertp 1:40 9. Aug 2005 (CEST)

Hallo Robertp, keine Belästiung, ist schon in Ordnung :-) Wir sollten dazu m.E. mal Quellen sammeln. Also, Google angeworfen:

• Ergebnisse 1 - 10 von ungefähr 168.000 für jbod controller. 9 der Treffer sind konkrete Produkte, davon 4 für RAID Controller, die auch JBOD machen und 5 für Nur-"JBOD-Controller" (also einfache Festplattencontroller).
• Ergebnisse 1 - 10 von ungefähr 164.000 für raid jbod controller - alles Beschreibungen von RAID Controllern, die auf Wunsch auch JBOD machen können sollen
• Ergebnisse 1 - 10 von ungefähr 883 für jbod i/o modul, dabei beschreibt kein Treffer ein I/O Modul im Sinne von JDOD
• Ergebnisse 1 - 10 von ungefähr 60 für jbod "i/o modul", das sind mir zu wenige Treffer als Quelle für WP
• Ergebnisse 1 - 10 von ungefähr 616 für jbod "i/o module", Treffer 1 und 2 sind HP (aha! Machst du viel mit HP? :-), die anderen beziehen sich nach flüchtiger Durchsicht zum Teil auch auf HP Produkte, ah, oder auf Sun.

Das bestätigt, was mein Know-How Horizont beinhaltet: Festplatten-Controller heißen Festplatten-Controller. "JBOD Controller" ist sicherlich dasselbe. Bei HP und Sun heißen die auch I/O Modul (wobei die Bezeichnung finde ich, viel ungenauer ist, als Festplatten-Controller). Viele RAID Controller können auch die Nicht-RAID Betriebsart JBOD.

Und noch was: JBOD ist nicht dasselbe wie lineares Zusammenschalten von Festplatten zu einem großen Volume, wie es falsch unter http://www.zdnet.de/enterprise/server/0,39023275,39119381-6,00.htm und in en:Redundant array of independent disks steht. Bei der Werbung zu den ganzen RAID Controllern steht "JBOD" in einer Reihe mit RAID Leveln, die sie können; zumindest bei 3ware Controllern weiß ich genau, dass sie keine Zusammenschaltung von Festplatten namens "JBOD" kennen.

Hat noch jemand bessere Quellen? Viele Grüße Kruemelmo 21:58, 9. Aug 2005 (CEST)

Hallo Kruemelmo und alle anderen. Am sinnvollsten erscheint es mir, das Thema JBOD an den Wikipedia-Artikel gleichen Namens zu adressieren. Zum ersten, weil das Befassen mit diesem Thema den RAID-Artikel sicherlich sprengen würde (wie die subtilen Diskussionen hier zeigen), und zum zweiten, weil der JBOD-Artikel gegenwärtig noch sehr kurz ist. Im RAID-Artikel selber könnte man in einem einzelnen Satz (Formulierungskünstler gesucht :-) den Unterschied herausstellen und einen Link zum JBOD-Artikel hinterlegen. Viele Grüße Robertp 22:32, 9. Aug 2005 (CEST)

PS: Sicherlich werden wir ins in der Diskussionsrunde zum JBOD-Artikel wieder treffen ;-)

RAID 4

Bitte helft meinem Hirn auf die Sprünge:

Warum stellt im RAID 4 die fest definierte Paritätsplatte einen Flaschenhals dar? Physikalisch ist sie ja nichts anderes als eine weitere Datenplatte. IMHO sollten zudem die Paritätsdaten vor dem Schreiben im Speicher berechnet und danach als Stripe (Parität + Daten) auf das Array geschrieben werden. NetApp tut dieses recht erfolgreich und hochperformant.

--strangemeister@work 14:00, 9. Aug 2005 (CEST)

Die Bezeichnung Flaschenhals finde ich unglücklich, ist aber nicht falsch: Bei einem normalen RAID4 kann man nicht schneller schreiben, als auf eine der Platten geschrieben werden kann. Da die Parity-Platte immer mitbeschrieben werden muss, stellt ihre maximale Schreibgeschwindigkeit die maximal mögliche RAID4-Schreibperformance dar. Weiterer Nachteil bei RAID4 ist, dass bei jedem Schreibvorgang eine der normalen Disks und immer die Parity-Disk in Benutzung ist, d.h. die Parity Disk fällt viel früher aus als die anderen (die Schreibvorgänge verteilen sich ungleich auf die Platten).

NetApp umgeht diese Probleme, da bei einem NetApp-System eigentlich auf das NVRAM geschrieben wird. Die Schreibvorgänge werden dann nachgelagert auf die Platten geschrieben, dadurch können die Schreiboperationen auf die Platten verteilt werden, alle Platten werden gleichstark genutzt.

Mckuno 14:14, 9. Aug 2005 (CEST)

Ich sehe den Flaschenhals bei RAID4 ebenfalls nicht. Angenommen ich will 128 kb abspeichern und habe ein RAID4 aus 4 Nutzplatten und einer Paritätsplatte. Soweit ich das verstehe werden dann auf die 4 Nutzplatten je 32 kb Nutzdaten und auf die Paritätsplatte 32 kb Paritätsdaten geschrieben. Es ergibt sich also eine Durchsatzsteigerung um den Faktor 4 beim Schreiben.

Wie kann man unter diesen Voraussetzungen davon sprechen, dass die Paritätsplatte der Flaschenhals wäre? Oder begehe ich einen Denkfehler?

MagicMuscleMan 22:30, 3. Okt 2006 (CEST)

Hier mal zwei Dokumente, die ich auf die Schnelle gefunden habe:

[2] „The write performance however is abysmal! Whenever new data is written to any member disk, the corresponding parity strip must be updated. This means that the parity disk becomes a bottleneck...“.

[3] „Writes, however, require that parity data be updated each time. This slows small random writes, in particular, though large writes or sequential writes are fairly fast.“

Bei RAID5 ist die Parity quasi mit-gestriped, daher ist es mit RAID5 weniger Problematisch wenn an verschiedene Stellen des RAIDs geschrieben wird, da auch das Schreiben der Parity über alle vorhanden Spindeln verteilt wird, wohingegen bei RAID4 dann auf der einen Parity-Platte viel geseekt werden muss, was eben bei „small random writes“ die Performance drückt.

--Kvedulv 18:58, 5. Okt 2006 (CEST)

und schon wieder RAID 4

Im Absatz für RAID 4 steht:

"Ein Vorteil von RAID 4 besteht darin, dass bei einem Ausfall einer Datenplatte eine "vorgenullte" Datenplatte eingesetzt werden kann. Dadurch wird eine zeit- und rechenintensive Wiederherstellung vermieden, dass RAID-4-System kann ohne Einschränkungen weiterbetrieben werden."

Das kann aber so nicht richtig sein, da ja durch den Ausfall einer Datenplatte die verlorenen Daten aus der Parity und den restlichen Datenplatten neu berechnet werden muß. Im Gegensatz zu RAID 5 muß nur die Parity nicht neu berechnet werden. Das Thema mit den "ausgenullten" Platten bezieht sich auf die Hot-Spare-Platte(n). Beim Einbinden einer neuen Platte ist diese sofort im Array verfügbar, da keine Parity berechnet werden muß, da diese von der "ausgenullten" Platte nicht verändert wird.

Oder liege ich da falsch???

--strangemeister@work 15:24, 22. Sep 2005 (CEST)

RAID 0 für normale Anwender nutzlos bzw. "gefährlich" ?!

Ich hab dem Artikel mal zwei kritische Links angefügt, in denen die Reallife Performance von RAID 0 Systemen untersucht wird. Ergebnis beider Artikel: "Invenstiert euer Geld lieber in andere Dinge!". SO wie es scheint, gewinnen die RAID 0 Systeme zwar theoretische Benchmarks mit ein paar Prozentpunkten Vorsprung, Spiele and Anwendungen bleiben aber völlig unbeinflusst. Bevor man sich also der Gefahr des völlig Datenverlustes beider PLatten aussetzt, sollte man lieber beide Platten für sich laufen lassen. Meiner Meinung nach sollte auf diesen Aspekt im Artikel deutlich hingewiesen werden, da in der Bevölkerung der Unglaube weit verbreitet ist, dass sich ein RAID 0 System für normale User lohnt. Wie seht ihr das? 195.14.206.220 18:54, 23. Sep 2005 (CEST)

Ich halte den "strengen Warnhinweis" für irreführend! da bei Festplatten die "Ausfallwarhscheinlichkeit" ja nicht konstant ist, sondern mit zunehmender Betriebsdauer steigt, sollte man eher über die MTBF nachdenken... und hier ergibt sich m. E. kein schlechteres Bild in RAID0 als bei einer einzelnen (größeren) Festplatte - beim alternativ unabhängigen Betrieb der beiden im RAID0 laufenden Festplatten würde halt beim Ausfall der ersten Platte nur ein Teil der Daten verloren gehen... Da man aber vorher nicht weiß, welche Platte zuerst ausfällt, hilft das nichts. klar ist: es bringt keine zusätzliche Sicherheit, aber m. E. auch keinen Sicherheitsverlust - sobald die erste Platte ausfällt, hat man so oder so ein Problem... das Problem ist bei RAID0 zwar größer, aber für die Praxis halte ich das fürbedeutungslos - Meinungen?! PS: nochmal etwas mathematischer - die Ausfallwahrscheinlichkeit des Gesamtsystems steigt zwar, aber die Ausfallwahrscheinlichkeit für eine beliebige Datei, von der ich vorher nicht weiß, auf welcher der beiden Platten sie liegt, bleibt gleich 84.131.133.114 23:43, 6. Okt 2005 (CEST)

Mit normalen Onboard Kontrollern kann man bei hoher CPU Last auch keinen Geschwindigkeitszuwachs erwarten. Bei Hardware-RAID Kontrollern ist der Performancezuwchs jedoch in jeder Situation gegeben, die dem Kontroller erlaubt, die entsprechende Datenmenge in kurzer Zeit in den Arbeitsspeicher zu Pumpen. Zudem muessen die Dateien entsprechend gross sein, und der Kontroller mus ueber einen gewissen Speicherausbau verfuegen.

Wenn bei RAID0 eine Festplatte ausfällt, ist das gesamte Array unwiederbringlich zerstört. Es gehen also nicht nur ein paar Dateien verloren, sondern alle Dateien sind futsch. Dies hängt damit zusammen, dass der Controler nicht Dateien sondern einzelne Blöcke auf den beiden Platten verteilt. Daher steigt auch die Ausfallwahrscheinlichkeit einer einzelnen Datei, wenn auf einmal eine der Platten defekt ist. Der Warnhinweis ist also durchaus berechtigt. boente 16:00, 10. Okt 2005 (CEST)

Mehr Geschwindigkeit - kürzere Ladezeiten. Ich habe 2x RAID 0 auf je 3 HDDs und merke den Unterschied. But Good Night - Ich schreib morgn weidda. --Overclocker 23:16, 24. Aug 2006 (CEST)

Nicht alle Daten sind futsch, aber die meisten. Wiederherstellbar ist etwa die Hälfte aller Dateien, welche kleiner als die Blöckgrösse (Stripe Size) sind.

Tatsächlich ist es so, dass (Normal-)Anwender, die RAID verwenden, häufiger Datenverlust erleiden als ihre non-RAID Kollegen. Und zwar nicht durch Festplatten-Ausfall, sondern durch falsche Sicherheit, die der RAID bietet. So ersetzt ein RAID kein Backup, sondern bietet einzig auf Hardware-Ebene zusätzlich Sicherheit. Durch versehentliches Löschen oder bösartige Software kann so Datenverlust entstehen, der durch vorsichtshalber angelegte Backups nicht passiert wäre. Dies außen vorgelassen ist aber natürlich die Ausfallwahrscheinlichkeit bei RAID 0 höher als bei einer einzelnen Festplatte. Daher sollte dieser für eher unwichtige Daten eingesetzt werden, bei denen aber gesteigerte Geschwindigkeit von Vorteil sein kann. Obeliks 21:18, 19. Apr 2006 (CEST)

Ich stimme meinem Vorredner absolut zu. Ein RAID dient entweder nur zum Steigern der Peformance, oder der Erhoehung der Ausfallsicherheit des entsprechendem Geraetes. Mehr nicht. Mit Datensicherheit hat RAID absolut nichts zu tun. Dieses ist hoechstens als Gimmick zu verstehen, worauf man nicht bauen sollte. Dafuer gibt es andere Mittel. Als Beispiel sei zu nennen, das das RAID selber einige " points of failure " mitbringt. Als Erstes waere da der hoffentlich vorhandene Hardware-RAID-Controller. Wenn dieser ausfaellt laesst er sich nur gegen kompatible Modelle austauschen, was soviel heist wie: man ist an einen Hardwarehersteller gebunden, wenn man seine Daten nach Ausfall des Controllers erhalten moechte. Als Zweites kommt die sensible Konfiguration. Wer unbedarft am RAID-Controller rumfummelt und nicht weiss, was er tut wird schnell ein Desaster erleben. Besonders bei Ausfall einer Platte ist mit extremer Vorsicht vorzugehen.

Zusammengefasst

Nacheinmal zusammengefasst:

1. RAID0 dient nicht der Versionierung der Daten und auch nicht der Vermeidung von unerwünschtem/verfrühten Datenverlust.
2. Bei Ausfall einer Disk in einem RAID0 ist das aufsetzende Dateisystem natürlich nicht vollständig verlustig gegangen, da selbstverständlich nicht nur die Rohdaten der anderen Disks sondern auch entsprechende Teile der Dateisystem-Meta-Information und der enthaltenen Dateien erhalten bleiben (bei 2 disks von denen eine ausfällt kann man natürlich nicht unbedingt sagen, dass die Hälfte der Dateien noch da ist (das hängt auch von der Stripe-Größe ab) aber ein guter Teil dürfte noch übrig sein - käme mal auf ein Experiment an...).
3. Zwecks Versionierung gibt es diverse verschiedene Dateisysteme (etwa das was damals auf den VAX Maschinchen lief: VMS) und ansonsten kann man ja "inkrementelle" Backups (auch welche, die nur die geänderten Bereiche einer Datei sichern; z. B. eine >10GB MPEG-Datei, die nur verlängert wurde, aber ansonsten gleich ist, braucht ja nur bezüglich der Verlängerung inkrementell gebackupt zu werden (der Rest ergibt sich schließlich aus den vorangegangenen Backups); hier sind auch Snapshots interessant) alle 10 Minuten veranstalten... Zwecks Backup-Management gibt es diverse nützliche Tools... Wer keine Backups mag, kann auf RAID0 eben nur unwichtige Daten speichern (z. B. Fernseh Filme im PVR Bereich)... Wer nicht schnell genug Versionen/Backups hinbekommt, der hat auch mit RAID1 (selbst mit 10-facher Spiegelung) unter Umständen wenig Freude (eine kurze Reihe merkwürdiger Handbewegungen oder beim Staubwischen oder n Schuss Kaffee ins Gehäuse... Ich kann Euch sagen, es weihnachtet sehr...)...
4. Und ansonsten: RAID0 eignet sich eben eher für große Dateien, die schnell geladen/gespeichert werden sollen, damit das Striping eben so richtig zur Geltung kommen kann.

--213.54.79.206 11:32, 27. Aug 2006 (CEST)

Ich habe das mal eingepflegt... --213.54.79.206 11:43, 27. Aug 2006 (CEST)

Zur Wahrscheinlichkeit

Das ist ja so eine Sache mit der Stochastik/Kombinatorik... Da kann man sehr leicht falsch liegen, auch wenn man in Mathematik ansonsten sehr gut ist... Ein Gedanke, der die gestrige Darstellung im Artikel zu widerlegen scheint, ist sicherlich der folgende: "Wenn in einem Einzel-Platten-Filesystem diese einzelne Platte total ausfällt, ist das File-System mit Sicherheit total weg. Wenn in einem Filesystem auf einem 4-Platten-RAID0 eine Festplatte total ausfällt, dann steht man auch ziemlich dumm bis ebenso fertig da. Es ist nun also nicht zu erkennen, wieso eine Festplatte überhaupt völlig ohne Ankündigung total ausfallen sollte, und wieso eine Kombination von 4 kleineren, bescheideneren Platten X, die ersichtlich nur ein viertel der Arbeit verrichtet haben wie eine 4-fach-größere Platte Y, überhaupt eine höhere Ausfalls-Wahrscheinlichkeit haben sollte, zumal diese aufgemotzten riesenhaften schnell rotierenden Festplatten durchaus schneller am Ende ihrer Lebenszeit angekommen sein könnten (besonders wenn sie 4-mal so viel zappeln müssen)." Ohne Beweis (damit habe ich mich schonmal so lächerlich gemacht, dass es für die nächstens 100 Jahre reichen dürfte)... --213.54.67.25 11:31, 28. Aug 2006 (CEST)

Noch ein Nachtrag zur Wahrscheinlichkeit: Der Vergleich zwischen "4 100GB Festplatten als RAID0" und "4 Dateisysteme auf je einer 100GB Festplatte" hinkt schoneinmal weniger. Man kann hier sehen, dass bei gleichmäßiger (wie auch immer man das hinbekommen soll) Auslastung die MTBF für eine einzelne Festplatte sicherlich gleich ist. Alle 4 Platten jeweils als Gesamtsystem betrachtet haben im übrigen immernoch dieselbe (sic!) MTBF; jedoch(!) ist der Datenverlust und Reparatur-Aufwand bei RAID0 deutlich bis wesentlich (Totalausfall durch z. B. nur vier riesenhafte ausfüllende gleichgroße Dateien) höher. --213.54.67.25 15:15, 28. Aug 2006 (CEST)

Auch das habe ich einmal einzupflegen versucht... --213.54.67.25 15:15, 28. Aug 2006 (CEST)

Annahme Ausfallwahrscheinlichkeit = 0.02 = 2% (nicht unrealistisch bei 5 Jahren Betriebsdauer).

RAID0 fällt mit höherer Wahrscheinlichkeit aus, als Einzelplatte. Tod des RAID 0 bei Ausfall mindestens einer Platte

Wahrscheinlichkeit 0.98, das eine Platte in Ordnung bleibt. RAID 0 = 0.98 * 0.98 = 0.96, das alles in Ordnung bleibt. Ausfallwahrscheinlichkeit = 0.04 = 4%

Die Ausfallwahrscheinlichkeit zu nehmen und zu multiplizieren führt zu einem RAID1. Denn damit würde man den Totalausfall aller Platten ermitteln, was dem Ende des RAID1 entspricht.

Ausfallwahrscheinlichkeit = 0.02 ergibt den Totalausfall bei einer Wahrscheinlichkeit von 0.0004 = 0,04%

Bei einem RAID1,5 etc. ist zu bedenken, das es nur dann zu einem Totalausfall kommt, wenn der eingetretene Fehler bei einer Festplatte nicht repariert wird, bis die Festplatte ersetzt wurde.

Wird das System im Fehlerfall sofort gestoppt und die übrigen Festplatten fallen bei der Restauration nicht aus, wäre die Fehlerwahrscheinlichkeit = 0%

Zu bedenken ist noch für Desktop Anwender, die üblicherweise nur eine Platte verwenden, daß die MTBF bei einem RAID wahrscheinlich ansteigt, da die Platten in der Regel nahe beieinanderliegen und sich stärker gegenseitig aufheizen (meiner Erfahrung nach ca. 5 Grad). Dies führt zu einer Erniedrigung der MTBF (siehe ebenda).

Zur Berechnung einer MTBF für mehrere Systemkomponenten, von denen keine Ausfallen darf (wie bei einem RAID 0) gilt, den Kehrwert der Addition der Kehrwerte zu ermitteln.

RAID-MTBF = 1 / (1/MTBF-Disk1) + (1/MTBF-Disk2) + ... + (1/MTBF-Diskn) )

MTBF=500.000 Stunden pro Disk, RAID0-MTBF zwei Festplatten = 250.000 Stunden.

Betrachtung der MTBF bei einem RAID 5 unter Berücksichtigung, das eine Platte während der Restauration ausfällt, hier in einem "Vorlesungsartikel" der technischen Universität München: http://www-db.in.tum.de/teaching/ws0506/DBSYS/exercises/Loesung10.pdf

Halifir/Mai 2007

Kritik zum Link

Der Artikel unter http://ww1.4hf.de/2008/12/raid-system-in-realen-testvergleich.html ist auf aktuelle Systeme nicht übertragbar - Hier war der PCI-Bus das Problem. Sieht man sehr schön am RAID0 - während das 1 HDD System gegen Ende abfällt, weil die HDD nicht mehr als 70 MB/s schafft bleibt das 3 HDD System konstant bei ca. 95 MB/s, schon das 2 HDD System ist über die meiste Zeit am Limit. Bei den breiteren PCI-Versionen (64 bit, 66 Mhz, PCI-Express) sieht das ganz anders aus. Ich kann ja mal mit einem System (4x 36 Gbyte mit einem 64 bit HW-Raid) ein paar Experimente machen. -Mifritscher 12:21, 26. Sep. 2009 (CEST)

Frage

Ich hätte noch gerne eine Erwähnung wie das striping ausgesprochen wird ... striPPing oder straiping ?

"straiping" --Gruß Robertp 18:31, 5. Aug. 2005 (CEST)

RAID

• pro: Informativ, ansprechend und verständlich. --Flominator 7. Jul 2005 19:43 (CEST)
• guter Artikel, aber einige Dinge stören mich noch: Die Diagramme der einzelnen Raids könnte man zwecks besserem Layout als thumbs am rechten Rand einbinden, dann verschwinden die weißen Löcher. Den Glossar unten könnte man killen und den einzigen Begriff im Text erklären. Sonst stört das den Lesefluss. Bei den einzelnen Raid-Levels sollte noch geschrieben werden, wie hoch jeweils die Redundanz ist und wie sich jeweils die MTBF errechnet. Da gibts so hübsche Förmelchen.. ;-) Vielleicht würde auch ein Review nicht schaden. Die Wertung muss ich mir erst noch überlegen. --Kurt seebauer 7. Jul 2005 21:01 (CEST) Nachtrag: pro ist schon drin. Wir sind ja nicht bei Exzellenz. --Kurt seebauer 8. Jul 2005 11:51 (CEST)

Bilder sind inzwischen formatiert. --Flominator 7. Jul 2005 22:27 (CEST)

• Pro Bzgl. dem Glossar gebe ich Kurt Seebauer Recht. Ansonsten finde ich den Artikel auf jeden Fall lesenswert. -- Roffle 8. Jul 2005 08:30 (CEST)

Ich habe mal versucht, den Glossar aufzulösen. --Flominator 8. Jul 2005 15:58 (CEST)

Pro guter Artikel! Antifaschist 666 00:17, 11. Jul 2005 (CEST)

Pro Artikel ist inhaltlich korrekt soweit ich das beurteilen kann, zudem überwiegend leicht verständlich und kompakt, soweit ich sehe wurden auch die Kritikpunkte von Kurt Seebauer ausgemerzt --Mastacheata 15:07, 11. Jul 2005 (CEST)

Ich habe auch noch ne Frage, tut mir Leid wenn ich es im Text übersehen habe, wenn nicht wäre es vielleicht noch erwähnenswert: Brauche ich z.B. für RAID 0 alles identische Festplatten, oder muss nur die Speicherkapazität gleich sein oder kann ich sogar ganz versch. Platten nehmen (versch. Hersteller und versch. Kapazität)? Danke! Gruss Zoebby, 10. August 2005

Hallo Zoebby, für jeden RAID-Level sollten die Platten gleiche Kapazität, gleiche Umdrehungsgeschwindigkeit und gleiche Firmware haben. Sind vergleichbare Platten von verschiedenen Herstellern beteiligt, ist eine identische Firmware schwer möglich, aber ein vergleichbarer Firmware-Level kann durch einen Update auf den neusten Stand erreicht werden. Gruss Robertp 23:44, 10. Aug 2005 (CEST)

Hallo ich habe auch noch eine Frage: kann man einen RAID-10-Verbund nicht genauso wie einen RAID-01-Verbund mit nur 3 Festplatten betreiben? stelle mir das so vor: http://s2.imgimg.de/uploads/RAID10313002f95png.png --Gokupk 18:16, 21. Dez. 2009 (CET)

- 2006 -

Falsche Angaben zu Hamming-Codes bei RAID-2

Es gibt IMHO keine (10,2) Hamming-Codes mit 8 Bit Nutzdaten und 2 Bit ECC...

Soweit ich über Hamming-Codes gelesen hab:

für r>=3:

n = 2^r - 1 , Anzahl Bits im Code
u = n -r , # Daten-Bits
r , # ECC-Bits

Notation: (n,r)

bei RAID-2 soweit ich weiß (7,3) verwendet... Ergo 7 HDs, 4 mit Nutzdaten und 3 mit Fehlercodes.

Einwände?

- Arndt Faulhaber

Es ist völlig zutreffend, Arndt Faulhaber, dass es keinen Hamming-Codes mit 8 Nutz-Bits und 2-ECC-Bits gibt, da hierbei der Hamming-Abstand maximal 2 sein kann (siehe [4]). Jedoch finde ich, dass ein Code mit einem Nutz-Bit und 2-ECC-Bits ebenfalls die Eigenschaften eines Hamming-Codes hat (2 ist kleiner als 3). Aber was solls... ;-) --213.54.79.182 22:30, 16. Aug 2006 (CEST)

Ich habe das dann mal entsprechend eingebracht in den Artikel... --213.54.79.182 22:30, 16. Aug 2006 (CEST)

Frage, Risiko bei Raid 1

Stimmt es, dass zwei Identische Platten aus der selben Fertigung ein Risiko darstellen?

Bei einem Kollegen hatten 2 Platten gleichzeitig einen Fehler. Der professionelle Daten-Retter meinte, das kähme öfter vor, wenn die Platten aus der selben Fertigung des selben Tages kähmen.

Spricht etwas dagegen unterschiedliche Platten zu verwenden? (Aktuelles system Onboard LSI SATA Controller)

Danke Chris

Jein. Tatsächlich haben Festplattenchargen mit unter eine geringere Lebenserwartung. Dass aber zwei Festplatten GLEICHZEITIG wegen der "zu billigen" oder einer fehlehaften Fertigung kaputt gehen, ist quasi absolut unwahrscheinlich. Gehen zwei HDs wirklich gleichzeitig kaputt, ist kommt der Fehler mit 99.99999999999...% Wahrscheinlichkeit bei mindestens einer Festplatte von aussen. Soll heißen, entweder kommt der Schaden von "ganz aussen" (Netzteil, Controller, etc...) oder z.B. ein Kurzschluss der einen Festplatte zerstört auch die andere. Da spielt die Charge, der Herstellungstag KEINE Rolle. Richtig ist aber, dass bei einer schlechten Charge, die Chance relativ hoch ist, dass zwei (beide) Festplatten in relativer zeitlicher nähe kaputt gehen können. Und ja, besonders bei Heim-RAID-Controllern oder On-Board-Raid-Controllern vertragen sich zwei Festplatten(Hersteller) oft nicht oder sie müssen sogar ABSOLUT identisch sein. (nutze vier Tilden ~ zum Unterschreiben) --WikiMax 16:52, 3. Jan 2006 (CET)

Ich will Dir da mal widersprechen. Eine Festplatte muß ja nicht gleich totalausfallen. Es reichen einzelne Fehler auf den Platten. Wenn jetzt eine der beiden Platten wegen zu vieler Fehler gekickt wird, und man eine neue einbaut für den Resync, merkt man eventuell erst, daß die andere auch fehlerbehaftet ist. Und die Wahrscheinlichkeit, daß das an Produktionsfehlern der gleichen Charge liegt, ist sogar EXTREM groß. Ich hatte selber den Fall mit zwei IBM DTLA Platten, gleichzeitig gekauft, sind relativ gleich am Anfang hinüber gewesen - und damit auch in diesem Sinne zeitgleich. Ich kann definitiv nur jedem raten (und das unabhängig vom Raid-Level): Soweit möglich, keine Festplatten gleichen Typs verwenden. Will man ein Raid mit 5 Platten aufziehen, kauft man auch Platten von 5 Herstellern. Und will man mehr Platten ins Raid knallen als es Hersteller gibt, dann kauft man sich z.b. 5 Platten, wartet ein zwei Monate, und kauft sich dann nochmal 5 Platten. Und bevor man die Festplatten annimmt, kontrolliert man, daß die Platten auch tatsächlich ein anderen Produktionsmonat haben. --Bodo Thiesen 06:17, 10. Sep 2006 (CEST)

Man kann unterschiedliche Festplatten verwenden, wenn man einige Punkte beachtet. Die kleinste Platte bestimmt die Kapazität des RAID-Systems. Am besten rundet man diesen Wert nochmals auf das nächst kleinere GB ab, falls man mal eine Platte ersetzen muss und diese je nach Hersteller doch unteschiedliche Nettokapazitäten bei der gleiche Grösse haben. Festplatten mit unterschiedlichen Leistungswerten (Datentransferrate, Zugriffszeit & Cache), können die Gesamtleistung des RAID-Systems negativ beeinflussen. So kann beispielsweise die schnellere Platte mehr belastet werden, da diese die geforderten Daten meist schneller anliefert, und fällt infolge dessen früher aus als erwartet. Oder es entstehen durch Asynchronitäten beim Datentransfer längere Wartezeiten als man es, bedingt durch die langsamste Platte im System, erwarten würde. Mein Vorschlag: 2 oder 4 gleiche Festplatten kaufen, diese jedoch mit einem zeitlichen Abstand von beispielsweise je etwa 100 Stunden (etwa 4 Tage) in Betrieb nehmen.

RAID 0+1 auch mit 3 Platten möglich :-)

Ich habe heute eine Korrektur eingefügt. Es gibt auch ein Raid 0+1 über 3 Platten. Wer's nicht glaubt: kann man z.B auf einem Mylex eXtremeRAID 2000 Controller einrichten.

Die Platten werden dabei jeweils zu 50% mit Nutzdaten belegt, die übrigen 50% jeder Platte enthalten eine Kopie der Nutzdaten einer der anderen Platten. Die Nutzdaten sowie die gespiegelten Daten werden gestriped. Bei drei Platten sieht das so aus:

Platte A: 50% Nutzdaten + 50% Spiegelung der Nutzdaten von Platte C

Platte B: 50% Nutzdaten + 50% Spiegelung der Nutzdaten von Platte A

Platte C: 50% Nutzdaten + 50% Spiegelung der Nutzdaten von Platte B

Die Nutzdaten werden dabei ebenso wie die gespiegelten Daten RAID 0 typisch über die Platten A, B und C gestriped. Bei Ausfall einer Platte sind immer noch alle Daten vorhanden.

Stephan

Und der Sinn geht gegen 0. Bei 3 Platten nur 50% Kapazität nutzen - bei Ausfallsicherheit für eine Festplatte, da gibt mir RAID5 bei gleicher Ausfallsicherheit 66.6% Kapazität. Erog: Wieder mal ein Feature, das die Welt nicht braucht. --Bodo Thiesen 06:20, 10. Sep 2006 (CEST)

"Symbolische Darstellung von RAID 10 und 01"

Ich schlage vor, das Bild zu löschen. Es sagt nicht mehr aus als der Text. Besonders gelungen ist es auch nicht. --Eike 16:57, 20. Jan 2006 (CET)

Aber so sieht man SOFORT, ohne zu lesen, wie es aufgebaut ist! Behalten. --Overclocker 10:15, 25. Aug 2006 (CEST)

KombinationsRAIDs

Ist es wirklich nötig, jede theoretisch machbare RAID-Kombination hier durchzuspielen?

Ach ja, und setzt jemand hier ernsthaft (also im echten gewerblichen Umfeld) Kombinationen aus "RAID 0" und RAID 1 ein? (ich meine hier auch keine Ich-AG, sondern "wirklichen gewerblichen Einsatz".) --WikiMax 17:26, 24. Jan 2006 (CET)

Versteh die Frage nicht; RAID01 bzw. RAID10 ist bei Systemen der Enterprise Klasse Standard. Früher hat man jede Spiegelhälfte gestriped und dann erst gespiegelt heute geht man dazu über erst die Disks einzeln zu spiegeln und dann zu stripen. Nzlwf8 08:35, 27. Jan 2006 (CET)

RAID01/10 soll bei der "Enterprise-Klasse" Standard sein? Enterprise bedeutet Unternehmen. Auf Server in Unternehmen setze ich RAID5 (bei Hochverfügbarkeit im Cluster, DFS) ein, aber keine Spiegelung und schon gar kein RAID0. Die Spiegelung setzte ich zuhause ein, da hier auch keine wirklich große Datenmengen anfallen oder bei kleinen Zweitservern oder Kleinstunternehmen (hatte ich mit Ich-AG umschrieben). Auf einer Arbeitsstation wird sowieso nichts gespeichert, also brauche ich auch kein RAID1. Soll es eine "superschnelle" Grafik-Workstation sein, RAID0. Aber keine Kombination, denn es wird ja nichts (außer zum Bearbeiten) gespeichert. Platte kaputt, neue rein, Image zurück oder Mac-OS/WinXP schnell installiert, Photoshop, etc. ist auch schnell drauf. Geht genauso schnell wie ein defektes RAID wiederhergestellt. Ich kenne RAID01/10 nur von "Spielern", aber ich kenne nicht die ganze Welt, daher meine Frage. Aber RAID01/10 als Standard im Unternehmensbereich KANN ich mir nicht vorstellen und wenn ich die Angebote meiner Server-Lieferanten ansehe IST es auch maximal Substandard für Kleinstserver. (Vielleicht bin ich ja auch nur zu "konservativ") --WikiMax 09:44, 27. Jan 2006 (CET)

RAID10 ist defakto Standard für Datenbankserver (o.ä.) die sehr große Datenmengen aktualisieren (updates, inserts) bzw. bei denen sich die häufig verwendeten Daten nicht im Pagecache halten lassen und somit schneller Diskzugriff unumgänglich ist. Raid5 ist unbestritten langsamer und Raid0 wäre, wie du schon sagtest, wahnsinn für solche Maschinen. Die einzige alternative zu Raid10 wären hier Solid State disks, und da ist ein Raid10 mit zwar nur 50% nutzbarer Kapazität trotzdem billiger. --Robe 03:53, 03. Mar 2006

Für die Kombinations-RAIDs reicht eine einzige Überschrift. Es sollten nur die gebräuchlichsten aufgeführt werden und eine Bemerkung, dass man natürlich auch alles andere kombinieren kann. Insbsondere die Einzeiler "Ein RAID 03-Verbund benötigt mindestens sechs Festplatten.." können weg.

Ein Artikel sollte besser werden. Besser wird er nicht unbedingt dadurch, dass er länger ist. Kruemelmo 16:08, 30. Jan 2006 (CET)

Ausfallsicherheit bei RAID 1

Die Ausfallsicherheit von RAID 1 ist in der Tabelle mit n/2 angegeben. Dies ist eigentlich falsch, da die minimale Ausfallsicherheit von beliebigen Platten nur 1 ist. Zwar ist die Wahrscheinlichkeit gering, dass genau die 2 gespiegelten Platten ausfallen, hier sollte aber eigentlich immer vom ungünstigsten Fall ausgegangen werden. Gendo 15:02, 14. Mär 2006 (CET)

Lesen und verstehen: Es ist angegeben wieviel Platten Ausfallen dürfen(!) ohne dass Datenverlust auftritt (und dies ist EXAKT! n/2) und nicht die Wahrscheinlichkeit! --WikiMax 16:00, 14. Mär 2006 (CET)

Nachtrag: Übrigens die Wahrscheinlichkeit dass eine (der beiden) Platte ausfällt ist ungefähr doppelt so hoch (wenn für alle Platten idententische Ausfallwahrscheinlichkeiten angesetzt werden), wie das eine Einzelplatte ausfällt. (Platte 1 oder Platte 2 oder beide Platten). Die Wahrscheinlichkeit dass beide PLatten gleichzeitig (oder extrem kurz hintereinander delta-t) ausfallen, so dass Datenverlust auftritt ist sehr gering aber IMHO quasi nicht zu berechnen, bzw. bedarf der Definition von delta-t. Auf jeden Fall kann man die Wahrscheinlichkeit nicht global angeben, den jedes Festplattenmodell, jede Bau-Charge hat eine andere Ausfallwahrscheinlichkeit. Die (unterschiedlichen) MTBFs sind sowieso nicht "echt", sind nur "Marketing-Prognosen". --WikiMax 16:07, 14. Mär 2006 (CET)

Ich behaupte, dass ein RAID 1 aus beliebig vielen Festplatten (>= 2) bestehen kann, die alle den selben Dateninhalt haben. Dabei können n-1 Platten ausfallen, ohne dass ein Verlust auftritt. Wie kommt man denn bitte auf n/2? Das gilt wohl eher für RAID 10! Obeliks 21:05, 19. Apr 2006 (CEST)

Nachtrag: Genauer gesagt ist es bei RAID 10 so, dass zwischen (n/2)-1 und n-2 Platten ausfallen können, jenachdem welche. Sicher ist es aber natürlich nur bei der unteren Grenze. Obeliks 22:20, 19. Apr 2006 (CEST)

Was ist denn n für Dich bei RAID10? Wenn ich aus 4 disks ein RAID10 bastel (also RAID0(RAID1/a[n],RAID1/b[m])/c mit n disks in a und m disks in b), dann kann man in a höchstens auf n-1 disks gleichzeitig verzichten (also in der resynchronisations-phase sieht es ersichtlich anders aus) und in b höchstens auf m-1 disks gleichzeitig (da die resynchronisation hier ersichtlich wie folgt stattfinden könnte: disks A und B sind OK und disks C und D sind frisch hinzugekommen: dann könnte man mit A unten beginnend C sync-en und mit B oben beginnend D synchronisieren und über die Fortschritte quasi Buch führen (das macht durch aus Sinn bei SATA oder mehreren PATA controllern), so dass man dann schließlich, falls A und/oder B während der resync-phase ausfallen, immerhin vielleicht noch 2 halbe hat...)... --213.54.79.206 10:34, 27. Aug 2006 (CEST)

Ich hab es dann mal geändert... --213.54.79.206 10:34, 27. Aug 2006 (CEST)

Wieso steht da eigentlich inzwischen n − 1? Darüber hat sich heute unser Professor lustig gemacht. --77.7.11.126 19:52, 17. Jan. 2008 (CET)

Wenn ich n Festplatten in einem Raid 1 zusammenschalte, können in jedem Fall n-1 Festplatten ausfallen, ohne dass Datenverlust entsteht, da sie alle dieselben Inhalte haben (daher ja Spiegelung). Ich änder das jetzt.--141.48.183.252 17:57, 9. Mär. 2009 (CET)

FakeRaid

(Ich gehe im Folgenden von Raid0 aus) Im Artikel ist ja bereits angesprochen, dass es langsamer ist als echtes Hardware-Raid, trotzdem sollte erwähnt werden, dass es immer noch schneller ist als gar kein Raid. Zu möglichen Fehlern sehe ich nicht den Unterschied, ob nun der Fakeraid-Controller einen Fehler macht und die Daten zerschießt oder der Hardwareraid-Controller. Zudem finde ich fehlt der Hinweis, dass das wiederherstellen eines Hardware-Raids (Raid 1 bzw. 5) oft viel komplizierter ist als bei einem Fakeraid, weil die Controller hier ihre Eigenarten haben, sodass man nicht einfach an einen anderen Controller wechseln kann. --Treysis 15:22, 31. Mai 2006 (CEST)

Ich habe bisher noch nie einen Fake-RAID-Controller gesehen der einfach zu konfigurieren waere, und obendrein auch noch vernuenftige Features die fuer den sicheren Betrieb eines RAIDs erforderlich sind, mitbringt. Die wohl beste Menuestruktur kommt wohl von ICP-Vortex Controllern. Hier kann selbst der blutigste Anfaenger ein RAID aufsetzen. Man muss eigentlich nur wissen was man will. Und erfahrene Anwender koennen erweitertes Menue freischalten, welches mehr Features anbietet als alle anderen Controller, die ich kenne.

Bei den anderen Controllern hilft aber immer der Blick ins Handbuch. Theoretisch macht es wirklich keinen Unterschied, ob der HW-Controller oder SW-Controller ein RAID zerschiesst. Bei dem SW-Controller reicht meistens ein instabiles System, oder ein Ausfall der Stromversorgung, und schon wirds lustig. Bei einem HW-Controller kann man per Pufferbatterie und/ oder deaktivierten Schreibcache auf den Festplatten selber oder des Controller-Puffers fuer Ausfallsicherheit sorgen. RAID ist uebrigens nicht IMMER schneller als eine normale Platte. Dateien, die kleiner als das Stripe sind usw. Fuehren zu enormen Performanceeinbruechen. Selbst SCSI/SAS Platten und Controller sind davon nicht verschont. Der groesste Vorteil von HW Controllern liegt im Onboard-Cache und der CPU/XOR-Engine. Ausserdem sieht das Betriebssystem nicht die Physikalischen datentraeger, was enorme Vorteile hat.

Rechenbeispiel zur Verfügbarkeit von RAID6 im Vergleich zu RAID1

Ich habe da einmal ein kleines C/C++-Programm geschrieben, das -glaube ich- korrekt ist:

#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int choose(int a, int b) {
       int z = 1;
       for (int i=b+1; i<=a; i++)
               z *= i;
       int n = 1;
       for (int j=a-b; j>1; j--)
               n *= j;
       return z/n;
}

int check(int p) {
       bool bad = false;
       char c = 0;
       bool was = false;
       for (int i=sizeof(p)*8; i>0; i--, p>>=1) {
               const bool is = (p&1) != 0;
               if (is)
                       c++;
               if (is && was)
                       bad = true;
               if ((i&1) == 0)
                       was = is;
               else
                       was = false;
       }
       return bad?c:-1;
}

int main(int argc, char ** argv) {
       const int n = atoi(argv[1]);
       const double p = 1./atoi(argv[2]);

       double q6 = 0;
       for (int i=0; i<=2; i++)
               q6 += choose(n+2,i)*pow(p,i)*pow(1-p,n+2-i);
       printf("RAID6: %.9f\n",q6);

       double q1 = 0;
       for (int i=(1<<(2*n))-1; i>=0; i--) {
               const int c = check(i);
               if (c >= 0)
                       q1 += pow(p,c)*pow(1-p,2*n-c);
       }
       q1 = 1-q1;
       printf("RAID10: %.9f\n",q1);

       return 0;
}

Die Größe 1/p soll dabei die mittlere Anzahl der Zeiteinheiten angeben, die verstreichen, bevor eine Festplatte ausfällt (Erwartungswert; Normalverteilung?); die Länge einer Zeiteinheit sei dabei so gewählt, dass die Regeneration des RAID mittels Hot Spare Discs binnen einer Zeiteinheit stattfinden kann; wobei diese Annahme etwas Wirklichkeits-fern anmutet - aber vielleicht passt es ja... Ich finde es ganz bemerkenswert, dass RAID10 offenbar wesentlich unsicherer ist (bei gleicher Nutzdaten-Menge) als RAID6 (wenn man einmal die Ausfallswahrscheinlichkeit einer einzelnen HardDisc p bei beiden RAID-Formen als gleich annimmt, was wohl wegen der unterschiedlichen Hardware-Lastigkeit nicht ganz zutreffend wäre). Wenn einer oder eine will, kann er oder sie es ja validieren und ggf. einpflegen... :-) --213.54.74.233 01:41, 10. Jun 2006 (CEST)

Mein Compiler motzt wegen dem int i rum. Ich weiß aber nich wirklich warum (Bin noch Anfänger). --Overclocker 11:25, 6. Sep 2006 (CEST)

Benutzt Du denn einen C++ Compiler? Vielleicht einfach mal das kleine Programm als blubber.cc oder blubber.c++ oder blubber.cpp abspeichern... Ist jedenfalls Standard C++... :-) --213.54.79.79 10:18, 7. Sep 2006 (CEST)

Datei:C++ErrorRAID.png

Microsoft C++ 6.0 Pro. Gehts bei dir? --Overclocker 11:09, 7. Sep 2006 (CEST)

Das Programm ist offenbar ein C++98 Programm, MS C++ 6.0 ist irgendwo vorher hängen geblieben. Korrekturvorschlag: Das erste "for (int i=" in jeder Funktion durch "int i; for (i=" ersetzen, in den folgenden "for (int i=" einfach das "int" ersatzlos streichen. Hintergrund: Anfangs durfte man in C++ mit einem "for (int i=" ein i deklarieren, das ab dort in der gesamten Funktion (also auch nach dem Ende der for-Schleife) noch gültig ist. In C++98 wurde der Scope (Gültigkeitsbereich) geändert, ab dort existiert das i nur innerhalb der for-Schleife, in der es deklariert wurde. MS C++ 6.0 weiß das offenbar noch nicht ... Es folgt eine Version des Quelltextes, der hoffentlich nun auch unter MS C++ 6.0 compiliert, alternativ könnte man auch den Gnu C Compiler installieren. Der Quelltext compiliert sowohl mit einem C compiler, als auch mit einem C++ Compiler. --Bodo Thiesen 06:40, 10. Sep 2006 (CEST)

Mir war gar nicht mehr so recht bewusst, dass es was anderes als g++ und gcc gibt... Meine mentale Schwerbehinderung wird immer schlimmer... --213.54.83.34 01:47, 11. Sep 2006 (CEST)

Watt schlägste vor? Zitat:

Ich habe da einmal ein kleines C/C++-Programm geschrieben, das -glaube ich- korrekt ist: [...]

Sieht für mich nich so aus. Geht das Teil bei dir? Weil wenn ja dann kratz ich mir GNU drauf und dann schau mer weidda.

Ich habe den Code mit gcc 3.4.6 erfolgreich compiliert (mit -W -Wall gab'S nur die Warnung Warnung: nicht benutzter Parameter »argc«, die man getrost ignorieren kann). Davon abgesehen, gibt's die GNU Compiler Colletion auch für Windows, notfalls über Cygwin. --Bodo Thiesen 05:15, 20. Sep 2006 (CEST)

PS: Gehören die IPs 213.54.74.233, 213.54.79.79 und 213.54.83.34 3 verschiedenen Personen oder ist das immer die selbe, also der Programmierer?

Ich nehme an, es handelt sich immer um den gleichen (also dem Programmierer des Originalcodes). --Bodo Thiesen 05:15, 20. Sep 2006 (CEST)

PpS: Nich verzweifeln! --Overclocker 10:32, 11. Sep 2006 (CEST)

#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int choose(int a, int b) {
	int z = 1, i, j, n = 1;
	for (i = b + 1; i <= a; i++) z *= i;
	for (j = a - b; j > 1; j--) n *= j;
	return z / n;
}

int check(int p) {
	int bad = 0;
	char c = 0;
	int was = 0;
	int i;
	for (i = sizeof(p) * 8; i > 0; i--, p >>= 1) {
		const int is = (p & 1);
		if (is) {
			c++;
			if (was) bad = 1;
		}
		was = !(i & 1) ? is : 0;
	}
	return bad ? c : -1;
}

int main(int argc, char **argv) {
	const int n = atoi(argv[1]);
	const double p = 1. / atoi(argv[2]);
	int i;
	double q6, q1;

	q6 = 0;
	for (i = 0; i <= 2; i++) q6 += choose(n + 2, i) * pow(p, i) * pow(1 - p, n + 2 - i);
	printf("RAID6: %.9f\n", q6);

	q1 = 0;
	for (i = (1 << (2 * n)) - 1; i >= 0; i--) {
		const int c = check(i);
		if (c >= 0) q1 += pow(p, c) * pow(1 - p, 2 * n - c);
	}
	q1 = 1 - q1;
	printf("RAID10: %.9f\n", q1);

	return 0;
}

Datei:RAID2-C++Error2.png

Compiling Perfect, BUT... Wenn ichs ausführ gibbet n Problemschen:

Und was GNU C++ angeht, wollt ich mir noch letzte Woche installiern, but no time... --Overclocker 12:39, 10. Sep 2006 (CEST)

Der Fehler bei der Anwendung kann auch durch einen Bug vom Compiler oder durch ein Problem mit Windoof verursacht werden. Ich hatte mal so ein ähnliches Problem mit einem Fortran-Compiler, der .exe Dateien machen sollte, die sowohl in Win 98 als auch in XP gehen. In einem der beiden Betriebssysteme haben sie problemlos funktioniert, im anderen haben sie zu 70% einen kompletten Systemabsturz verursacht (ich weiß leider nimmer, in ob das unter 98 oder XP). Und das galt für alle Anwendungen, die ich mit diesem Compiler erfolgreich kompiliert habe, egal wie der Source Code war. -MrBurns 15:16, 12. Sep 2006 (CEST)

Also meinem Compiler kann ich nix vorwerfen! Der läuft wie ne 1! Andere Möglischgeidn? --Overclocker 11:31, 13. Sep 2006 (CEST)

Am besten gleich noch FreeBSD draufbügeln... :-) --213.54.84.148 18:34, 13. Sep 2006 (CEST)

RAID7

Das ist doch nicht euer ernst, oder? RAID7 existiert nicht. Der höchste RAID-Level, der mir bekannt ist, ist RAID6. Und er Autor schrieb ja bereits, daß RAID7 RAID5 ist. Nur weil es da einen Hersteller gibt, der einen Tollen Controller mit einem Tollen RTOS auf den Markt wirft, und das Ding dann RAID7 tauft, ist es noch kein neuer RAID-Level. Ich war mir mal so frei, und habe den Abschnitt hier hin verschoben. Sicherlich kann man irgendwo einen Hinweis anbringen, daß es ein Produkt namens RAID7 gibt, und erwähnt dann bei der Gelegenheit gleich, daß es sich nur um einen Marketing-Gag handelt, um dem Kunden vorzugaukeln, daß das Ding besser sei, als RAID5, aber in der Aufzählung der RAID-Level hat das meiner Meinung nach nichts zu suchen. Sonst baue ich mir morgen auch mal einen Raid-Controller, nenne den RAID2006 und erwarte, daß er auch hier beschrieben wird. --Bodo Thiesen 06:49, 10. Sep 2006 (CEST)

RAID 7

RAID 7 ist eine kaum verwendete Variante und basiert auf RAID 5. Allerdings läuft im Controller ein lokales Echtzeitbetriebssystem, welches die Lese- und Schreiboperationen steuert. RAID 7 unterstützt zusätzlich die Verwendung mehrerer Paritätsinformationen gemäß RAID 6.

Wenn du meine Meinung hören willst, ich würds im Artikel lassen! --Overclocker 12:32, 10. Sep 2006 (CEST)

Och nö! Hört sich mehr nach einem RAID Controller an, der RAID5 und RAID6 kann, und der ansonsten vielleicht(!) besonders geschickte Cache-Strategien kann... --213.54.84.148 18:34, 13. Sep 2006 (CEST)

RAID 7 ist die Entwicklung eines einzigen Herstellers und setzt natürlich den Einsatz der von ihm angebotenen Hardware und Software voraus, leider weiss ich den Namen der Firma nicht mehr.

Wo wurde jemals RAID-2 implementiert?

Aus diversen Vorlesungen im Informatikstudium habe ich folgende Quintessenz mitgenommen:

NIEMAND hat JEMALS RAID-2 implementiert.

Im Artikel steht "wurde bei Großrechnern verwendet". Ist das tatsächlich der Fall? Wenn ja, wer, wann, wo?

--Thorongil 17:07, 21. Sep 2006 (CEST)

Meines Wissens war das ursprüngliche RAID-Traktat nur ein rein theoretisches Papier und die Varianten 2, 3 und 4 haben fast keine Verbreitung gefunden.

RAID 10 schneller als RAID 1

Ich bin der Meinung, dass in der Übersichtstabelle der Kombinations-RAID-Systeme, das RAID 10 unterbewertet ist. Es hat dort die gleiche Lese- und Schreib-Leistung wie das RAID 1 System. Das kann aber nicht sein, da ein RAID 10 die Vorteile von RAID 1 und RAID 0 verbindet, was klar heisst, dass ein RAID 10 schneller liest und schreibt als ein RAID 1. Ich schlage vor, dem RAID 10 System je ein zusätzliches (+) beim schreiben und lesen zu geben. Auch ist zu erwähnen, dass bei einem RAID 10 System 4 von 6 Kombinationen von Doppelausfällen abgesichert sind, so dass man die Anzahl der ausfallbaren Festplatten mit 1.66 beziffern könnte (=1+4/6). Zudem ist beim RAID 10 die Leistungseinbusse beim wiederherstellen einer ausgefallenen Platte geringer als bei einem RAID 1, da hier nur 1 von 4 Platten wiederhergestellt werden muss und somit nur die Hälfte aller Lese- und Schreibvorgänge davon betroffen sind. Es wäre möglicherweise hilfreich, die Übersichtstabellen um eine Spalte zu erweitern, wo genau diese Leistungseinbusse bei der Wiederherstellung dargestellt wird. Ein RAID 5 aus 4 Festplatten (=75% Nutzkapazität) hat gegenüber einem RAID 5 aus 3 Festplatten (=66% Nutzkapazität) eine nochmals grössere Leistungseinbusse bei der Wiederherstellung, da die Daten der wiederherzustellenden Festplatte aus 3 anstatt nur aus 2 Festplatten berechnet werden müssen.

Ja klar, muss man ändern. Ich komm nur nich mit der Tabelle klar, kann bitte jmd der sich auskennt bei R10 je 1x supprt reinmachen? --Overclocker 13:38, 10. Nov. 2006 (CET)

Tabelle für die Performance-Daten

Die Tabelle für die Performance-Daten der RAID-Levels ist sowieso sehr schammig. Mit der Tabelle kann keiner etwas anfangen. Was bedeutet hier LESEN und SCHREIBEN (Random Zugriffe und/oder sequentielle Zugriffe)???

Anmerkung: Das kann aber nicht sein, da ein RAID 10 die Vorteile von RAID 1 und RAID 0 verbindet, was klar heisst, dass ein RAID 10 schneller liest und schreibt als ein RAID 1.

1. Es verbindet aber auch die Nachteile - Kombinationen mit RAID0 bedeutet immer Verlust an Ausfall- und Zugriffswahrscheinlichkeit.

2. Rein statistisch und zugriffzeiten-mäßig hat ein RAID1 (im Random-Mode) genau die gleiche Performance wie ein RAID10 (im Random-Mode), relativ auf eine Disk bezogen. Oder etwas anderes beschrieben, wenn man die I/O Rate von 4xRAID1 zum einem RAID10(4+4) vergleicht, wird man feststellen, dass die I/O Rate der 4 einzelnen RAID1 der I/O Rate von einem RAID10(4+4) entspricht. Auch die I/O Response Time beim Zugriff auf RAID10 und RAID1 sind fast gleich, wobei das RAID10 geringfügig höhere Zeiten hat. Dies hängt mit der Kombination RAID0 zusammen.

3. Rein theoretisch wird immer davon ausgegangen, dass die Array Bandbreite beim RAID10 gleich (Diskanzahl x Sustained Transfer Rate Disk) ist. Dies ist aber ein Trugschluss, weil mit jedem Zugriff auf die "logische RAID10-Disk" die Utilization steigt. Der erste sequentielle Zugriff kann die volle Bandbreite nutzen, der zweite Zugriff kann aber nur 100-X% der Bandbreite nutzen usw. Wenn man sich das reale Verhalten betrachtet, wird man folgendes feststellen: Ein RAID10(4+4) hat eine Array Bandbreite von 92MB/s. Bei einem Datei bzw. Logical Volume-Spreading über 4 x RAID1 erhält man eine Bandbreite beim seq. Zugriff von 112 MB/s.

Betrachtet man ein RAID1(1+1) mit einem RAID10(4+4) hat das RAID10 natürlich eine höhere Performance. Aber, kann man das überhaupt vergleichen. Einen Vergleich kann man nur durchführen, wenn man eine Normierung der Systeme durchführt, entweder auf relativer EIN-Disk Basis oder auf die Data Stripe Width bezogen.

Mfg. W. Kinder

RAID DP Abb. paßt nicht zu Text?

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle Q_4 = \operatorname{xor} \left( P_4, A_5, B_6, 0 \right)}

kommen in der Abblildung nicht vor.

Es fehlt auch eine Dartstellung der Diagonalen wie in: http://www.netapp.com/library/tr/3298.pdf (nicht signierter Beitrag von 62.159.90.138 (Diskussion) 17:27, 28. Dez. 2006 (CET))

- 2007 -

JBOD falsch beschrieben?

Im Artikel wird es so dargestellt (oder so verstehe ich es zumindest), als sei JBOD das gleiche wie der "normale" IDE-Modus wie man ihn von Standardcontrollern kennt. Das stimmt so soweit ich weiß, nicht. JBOD bedeutet vielmehr, dass die darunter zusammengefassten Festplatten vom System eben nicht einzeln, sondern als eine einzige wahrgenommen werden. Der Unterschied zum Striping besteht darin, dass die Daten nicht versetzt, sondern nacheinander geschrieben werden. Also Datei 1-10 auf Platte Eins, Datei 11-20 auf Platte Zwei usw.

So steht es im Handbuch meines ITE8212 RAID-Controllers und so sagt es auch der englische Artikel zum Thema. Ist die Angabe hier wirklich so falsch?

Verzeihung, sehe gerade dass das schonmal diskutiert wurde, aber so wie es jetzt im Artikel steht ist es trotzdem nicht ganz richtig. Bei meinem Controller bezeichnet JBOD definitiv das lineare Zusammenschalten der Platten. Und mir scheint das in der Praxis (nach Google zumindest) auch die gängigere Definition zu sein. Am besten wäre daher wohl im Artikel beide Arten zu beschreiben und anzumerken, dass JBOD manchmal die eine manchmal die andere Möglichkeit beschreibt. --84.61.39.11 03:52, 19. Jul. 2007 (CEST)

RAID trotz vorhandener Daten??

ich hätt eine frage, kann man ein raid erstellen (mein interesse raid 5) mit 4 festplatten wenn auf 2 festplatten schon daten drauf sind oder muß ich die zuerst woanders auslagern und dann wieder draufkopieren? ich kann das nirgends aus dem artikel rauslesen. ich hab den controller AMCC 3ware 9500S-4LP, 64-bit PCI 66MHz. mfg die ip

bedingt durch die technologie ist raid 5 auf paritaet ausgelegt, beim erstellen eines neuen arrays gehen somit alle daten verloren - mag schon sein, dass es controller gibt, die beim erstellen des arrays bestehende daten neu verteilen, aber gesehen hab ich sowas noch nicht ;) --suit Benutzer Diskussion:Suit 19:31, 25. Jan. 2007 (CET)

Logische Fehler in der Übersichtstabelle

Habe grade die Übersichtstabellen dahingegend überarbeitet das die minumumanzahlen deutlich werden. Bitte mal sorgfältig auf fehler und verständlichkeit prüfen.

Dabei sind mir auch mehrere logische fehler aufgefallen (oder ich bin zu blöd ;-))):

• RAID5E und 5EE funktioniert offensichtlich nur mit n ≥ 4, ist ja schliesslich RAID5+Spare, nur werden die sparedaten über die platten verteilt.
• RAID3/4 braucht offensichtlich ≥ 3 platten um sinnvoll zu sein, obwohl auch 2 technisch auszureichen scheinen (=RAID1). Warum geht dann aber kein RAID5 auf 2 platten ? Nach meinem dafürhalten braucht eine parityberechnung mindestens zwei operatoren, eine parity aus einem operator (eine platte) ist mathematische Onanie ;-))
• RAID55 und RAID45 sind nur identisch wenn RAID4 mindestens 3 platten braucht (siehe logik oben). Sonst geht ein RAID45 auch mit 6 platten (auch wenn's dann eigentlich ein RAID15 ist)

--Peter.dittmann 21:46, 3. Feb. 2007 (CET)--Peter.dittmann 21:46, 3. Feb. 2007 (CET)

Zum XOR bei RAID5: Ich selbst habe es einmal so implementiert: 1. einer der Datenblöcke wird zum _vorläufigen_ Paritätsblock; 2. alle weiteren Datenblöcke werden mit dem _vorläufigen_ Paritätsblock mit XOR verknüpft. 3. Als Ergebnis erhält man die gesuchten Paritätsblock. -- Das geht auch mit einer Initialisierung des _vorläufigen_ Paritätsblocks mit Nullen... --85.212.17.115 08:07, 7. Feb. 2007 (CET)

Zu den Angaben für "n" in der Tabelle: Vorher war es sicher falsch ("=" wäre ja in den Fällen recht witzlos). Ich weiß nicht, wie das passieren konnte... --85.212.17.115 08:07, 7. Feb. 2007 (CET)

Raid 1 :n − 1 Diese Formel für die Ausfallsicherheit von Raid 1 stimmt wohl nicht ganz, oder? Das würde ja bedeuten, dass bei vier Festplatten (n=4) gleich drei Stück ausfallen dürfen, was natürlich Schwachsinn ist.

Eben nicht. RAID 1 ist einfache plattenspiegelung. Bei n=4 eben 3x gespiegelt. Solange eine davon noch läuft sind die daten OK. Nur kommt wohl kaum jemand auf die idee RAID 1 mit n>2 zufahren.--Peter.dittmann 13:21, 21. Apr. 2007 (CEST)

Wird der gleiche Inhalt auf alle Platten gleich gespiegelt, ist die Größe nicht n/2. Dies gilt für RAID 10, wenn jedes RAID 1 aus 2 Platten besteht.

Bei einer Spiegelung der Daten auf alle Platten ist die Größe k = 1 (wie im Text des Artikels "während die Kapazität des Arrays höchstens so groß ist wie die kleinste beteiligte Festplatte").

Entweder k wurde falsch eingetippt oder S.

RAID-1 laut Intention (Spiegelung über alle Platten): k=1 und S=n-1

Flasch: Immer nur zweifache Spiegelung: k=n/2 und S=1

[Halifir / Mai 2007]

• Matrix-RAID 1+0

Nicht Gesamtgröße k = "n + 3/4" (wäre zu schön, wenn man einen Zugewinn hätte)

Nur bei der Annahme, das die RAID 1 Partition genau die Hälfte der Festplattengröße beträgt, ergibt sich "n * 3/4" oder abhängig von der Partitionsgröße

Größe k = "n - (n * (Partitionsanteil RAID 1)/2)"

Partitionsanteil bei Halbierung der Festplattengröße = 0.5

• Matrix-RAID 5+0

(laut http://www.intel.com/design/chipsets/matrixstorage_sb.htm)

Größe k = (n * (Partitionsanteil RAID 0) + ((n - 1) * (Partitionsanteil RAID 5))

Partitionsanteil RAID 0 = 1 - (Partitionsanteil RAID 5)

[Halifir / Mai 2007]

raid 5 frage

was mir jetzt aus dem artikel nicht ganz klar wird, kann ein raid 5 (und darauf aufbauende natuerlich) erkennen, ob ein bit falsch geschrieben wurde/umgekippt ist/... oder kann es nur erkennen, wenn ne platte wirklich kaputt ist. wenn ich den abschnitt durchlese, komme ich zu dem schluss, dass das raid nicht auf grund der prüfsumme rausfinden kann, was kaputt ist, sondern nur das was kaputt ist. Elvis untot 09:07, 4. Mai 2007 (CEST)

Seh ich auch so, wenn die platte selber nicht sagt dass sie tod ist (bei offensichtlichem hardwaredefekt) kann RAID5 wohl nicht feststellen was defekt ist. --Peter.dittmann 22:54, 5. Mai 2007 (CEST)

Stimmt A XOR B nicht mit Parity auf C überein muss ein Sektor defekt sein. Es kann also sofort festgestellt werden, ob ein Bit defekt ist, auch ohne komplett Ausfall einer Platte. Aber von welcher der Platten das falsche Bit kommt, wüsste ich nicht wie das zu beantworten wäre. (Aber darüber habe ich mir auch noch keine Gedanken gemacht.) --(nicht signierter Beitrag von Halifir (Diskussion | Beiträge) 00:39, 26. Mai 2007 (CEST))

Da die Festplatte selbst für jeden Sektor Fehlererkennung betreibt (CRC), ist dieses Problem eher uninteressant. Wenn doch einmal so ein Fall auftritt, dann ist wohl eher das RAID5 falsch implementiert worden. --89.53.33.247 13:14, 19. Jun. 2007 (CEST)

Ich habe derzeit eine fehlerhafte Platte, die von sich aus keine Datenfehler feststelle, aber falsche Daten liefert. Die Platte liest sporadisch einfach mal einige falsche Sektoren ein. Die Sektoren sind an okay (mit allen CRC Prüfsummen), aber nicht die angeforderten Sektoren. (Prüfung durch Abspielen von mp3 Dateien von dieser Festplatte - die in keinen RAID Verbund mehr steckt. Es gibt beim Abhören zwischendurch Loops und kurze Ausschnitte aus anderen Stücken.)

Aufgrund dieser Erfahrung, das eine Platte selber keinen Fehler, aber definitiv falschen Daten liefert, ist die Frage, wie man feststellt welche der Platten defekt ist sehr wohl relevant und hat nichts mit einem falsch implementierten RAID5 zu tun.

Hier wurden die Daten von einer Sicherung wieder hergestellt. Erst die Zweitnutzung als MP3 Storage hat die Art des Defekts aufgezeigt. Halifir 16:55, 7. Aug. 2008 (CEST)

checksums anyone? ;-) siehe ZFS artikel

Überarbeiten

In Diskussion:Fehlerkorrekturverfahren#.C3.9Cberarbeiten schlage ich ein Konzept zur Überarbeitung des Artikel durch Ausgliederung eines Neuartikels anstelle der BKL Fehlererkennung vor, die hier auch benutzt bzw. die Belange dieses Artikels integrieren müßte --SonniWPDisk. 08:43, 14. Sep. 2007 (CEST)

Raid 5 auch mit 3 Platten möglich, bitte erwähnen

http://www.storitback.de/index.html?/service/raidlevel.html Man sollte vielleicht das Bild mit den 4 Platten korrigieren, denn natürlich kann man theoretisch unbegrenzt viele Platten verwenden, wichtig ist jedoch das Minimum, und das sind nun mal 3 Platten. --Schwarzschachtel 12:34, 2. Dez. 2007 (CET)

steht doch drinnen "Für den Preis eines RAID 5-Controllers mit (mindestens) drei Platten" okay, könnte noch eindeutiger drinnen stehen, aber es steht. --WikiMax 13:05, 2. Dez. 2007 (CET)

Welche RAID-Modi sind für Festplatten unterschiedlicher Größe geeignet?

Festplatten unterschiedlicher Größe können in einem NRAID oder JBOD zu einem virtuellen Laufwerk verbunden werden. Hierbei besteht keine Redundanz der gespeicherten Daten. (nicht signierter Beitrag von 87.187.71.94 (Diskussion) 00:20, 12. Oktober 2007 (CET))

- 2008 -

X-Raid

Ich finde es sollte einen Absatz zu X-Raid von Netgear bzw. Infrant geben!? --129.13.72.177 15:44, 23. Jan. 2008 (CET)

Parität bei Leseoperationen?

- Ein Nachteil bei klassischem RAID 4 besteht darin, dass die Paritätsplatte bei allen Schreib- und Leseoperationen beteiligt ist. Warum ist die Paritätsplatte auch bei Leseoperationen beteiligt? - 84.149.191.205 22:14, 24. Jan. 2008 (CET)

Link

Ist der von der IP gesetzte Link auf den Hersteller von Raidsystemen relevant. Belasse diese Version wegen dieses Linkws einstweilen ungesichtet. --Helmut Gründlinger 10:53, 20. Mai 2008 (CEST)

Nein, meiner Ansicht nach ein klarer Werbelink ohne relevante Inhalte. Habe die Änderung revertiert und damit gesichtet. --YMS 11:07, 20. Mai 2008 (CEST)

Ich sehe in dem Link auch überhaupt keinen Wert für WP. Danke @ YMS. Unabhänggig davon, ist wohl auch kein Hersteller, nur Wiederverkäufer Integrator und Dienstleister. --WikiMax 13:30, 20. Mai 2008 (CEST)

JBOD fälschlicherweise als NRAID bezeichnet?

Im Abschnitt JBOD steht, dass manche Programme JBOD fälschlicherweise als NRAID bezeichnen. Nach den beiden Beschreibungen und auch nach weiteren Recherchen war ich nicht in der Lage, Unterschiede zwischen den beiden Verfahren zu erkennen. Gibt es welche? Wenn nicht, müsste das "fälschlicherweise" da weg. --LonelyPixel 10:56, 11. Sep. 2008 (CEST)

bei nraid stehen die platten in verbund zueinander - via nennt das zb "spanning" - es werden einfach alle platten zusammen als ein volume zur verfügung gestellt und dem betriebssystem als eine platte vorgegaukelt (ohne performancegewinn)

bei jbod sind die platten einzeln ansprechbar (jede für sich) und hängen nur gemeinsam am kontroller - je nach hersteller beizeichnet aber jbod auch das, was andere hersteller unter spanning oder nraid verstehen

zusammengefasst "nraid" oder "spanning" bezeichnet es, wenn mehrere platten zusammen nach aussen hin ohne eigentlich raidfunktionalität auftreten

jbod ist je nach hersteller verschieden - ob da jetzt fälschlich was bezeichnet wird oder nicht sei dahingestellt, die frage ist wo es definiert ist --suit Benutzer Diskussion:Suit 23:08, 11. Sep. 2008 (CEST)

Nach meiner Kenntnis wird der Begriff JBOD von Raidcontroller-Herstellern verwendet, um darauf hinzuweisen, dass der Controller die Platten auch einfach als einzelne Platten ("Just a Bunch of Disks") ansprechen kann - im Unterschied zu Raid-Funktionen. Dann arbeitet der Raidcontroller eben als ganz normaler Festplattencontroller. Adaptec versteht unter JBOD (dort genannt "enclosure") ein dummes Festplattenrack mit mehreren einzelnen Platten, die allerdings von einem Raidcontroller auch als Raidverbund verwaltet werden können. Für sich sind sie aber nur JBOD. --Arjeh 13:53, 18. Sep. 2008 (CEST)

Nachtrag: Nach ein paar Recherchen musste ich feststellen, dass einige namhafte Controllerhersteller (z.B. Promise und Dawicontrol) unter JBOD tatsächlich NRAID verstehen, Suit hat demnach Recht. Man kann also nicht behaupten, es gäbe eine klare Definition (daher auch kein „fälschlicherweise“). Der Abschnitt JBOD muss überarbeitet werden. Ich will's versuchen. --17:26, 18. Sep. 2008 (CEST)

RAID 60

Der Dell PERC 6 hat laut Beschreibung die Möglichkeit RAID 60 (RAID 6+0) zu verarbeiten.

http://www.dell.com/content/topics/topic.aspx/global/products/pvaul/topics/en/us/raid_controller?c=us&cs=555&l=en&s=biz

http://www.dell.com/downloads/global/products/pvaul/en/RAIDPrimerWP.pdf (nicht signierter Beitrag von 212.202.161.228 (Diskussion) 13:17, 5. September 2008 (CEST))

SJBOD / SBOD

Eine Erklärung für SJBOD bzw. SBOD fehlt: Switched Bunch of Disks (storage networking)

-Obstfliege (nicht signierter Beitrag von Obstfliege (Diskussion | Beiträge) 23:24, 4. Juni 2008 (CEST))

Belege

Hier ein paar Belege die ich zu dem folgenden Satz im Artikel gefunden habe:

Der folgende Satz ist nicht hinreichend mit Belegen (Literatur, Webseiten usw.) ausgestattet. Die fraglichen Angaben werden daher möglicherweise demnächst gelöscht. Hilf Wikipedia, indem du die Angaben nachrecherchierst und gute Belege einfügst. Bitte entferne zuletzt diese Warnmarkierung.

Seit Mitte 2007 zeigen mehrere Studien, dass die S.M.A.R.T.-Daten zur Vorhersage eines Ausfalls auch nur sehr beschränkt nützlich sind.

http://www.heise.de/newsticker/meldung/85428 http://labs.google.com/papers/disk_failures.pdf (nicht signierter Beitrag von 87.79.136.131 (Diskussion) 20:59, 24. Jan. 2008 (CET))

- 2009 -

RAID 10

IMHO wird bei vielen Software-Implementationen und Hardware-Controllern RAID 10 mit 2 Platten unterstützt.

Schreiben parallel auf beide Platten, gelesen wird abwechselnd.

=> Datensicherheit + Performancesteigerung Lesen!

Wie sieht es mit der Erweiterbarkeit eines RAID 10 aus? Nach Informationen von "FSC" läßt sich ein RAID 10 nicht erweitern, sondern nur neu anlegen. Ist die Erweiterbarkeit von RAIDs generell ein Thema? (nicht signierter Beitrag von Poipoi (Diskussion | Beiträge) 10:00, 6. Apr. 2009 (CEST))

Hallo,

1. RAID10 mit zwei Platten ist NICHT möglich. Minimale Plattenanzahl = 4

2. NEIN, Erweiterbarkeit von RAID10 ist eigentlich kein Thema. Wichtig ist nur, dass der Controller oder das Storage-System die Methoden unterstützten.

A) Scratch Pad = Platte

Hier werden die hinzu zufügenden Platten als temporäre Zwischenspeicher für die Umlagerung der Blöcke genutzt. Ist aber sehr, sehr langsam.

B) Scratch Pad = Speicher

Im Gegensatz zur ersten Methode werden hier Teile vom Speicher für die temporäre Umlagerung der Blöcke genutzt. Diese Methode ist wesentlich schneller als die Erste und kommt bei Highend Storage-Systemen zum Einsatz.

Der Mechanismus ist bei beiden ähnlich. Ein oder mehrere komplette Stripe-Sets werden markiert, und in den temp. Zwischenspeicher kopiert. Zusätzlich wird jeweils ein Snapshot der Belegung vom Quelle-RAID und Ziel-RAID gezogen. Die Snapshots dienen dazu, das beim Fehlern während der Re-Kombination vom RAID die ursprüngliche Belegung schnell wiederhergestellt werden kann.

Die meisten Host-basierenden RAID-Controller unterstützen diese beiden Methoden jedoch nicht, weil die Zeit der Umlagerung einfach viel zu groß ist. Für die Umlagerung nach Methode A würde ein Host-basierender RAID-Controller bei einem RAID10 mit 4 Platten (145GB pro Platte) ca. 18 Tage benötigen. Nach Methode B bräuchte ein Host-basierender RAID-Controller auch noch 5 Tage.

3. gelesen wird abwechselnd - NEIN

Damit würde das RAID10/1 seinen lesenden Zugriffwahrscheinlichkeitsvorteil gegenüber einer Einzel-Disk verlieren. Es wird immer von der Disk im RAID10/1-Verbund gelesen, die als ERSTES den Block liefern kann. Alles andere würde statistisch betrachtet keinen Sinn ergeben.

Gruß WoKi (nicht signierter Beitrag von 89.48.28.161 (Diskussion | Beiträge) 19:43, 2. Mai 2009 (CEST))

Inexpensive / Independent

Inexpensive: Betonung des wirtschaftlichkeitsfaktors KT: Das ist ein extrem wichtiger Teil bei der Entscheidung für oder gegen RAID. Denn dieser Teil wird oft bei laienhaften Betrachtungen vernachlässigt. Es ist tatsächlich teurer Festplatten mit großer Kapazität so schnell zu machen wie kleine im Parallelzugriff. Das darf auch heute noch nicht vernachlässigt werden. Daher ist Independed zwar kein kompletter Blödsin, jedoch zu simpel für die Betrachtung!!! --213.182.228.30 19:09, 30. Mär. 2009 (CEST) Inexpensive? günstig? hm.. interessant cu cj

Nicht das RAID-Array als Ganzes, sondern die einzelne Platte ist im Verhältnis zu richtig großen, professsionellen Eisen günstig. Vor allem ist die Platte günstig tauschbar, wenn sie mal aussteigt. --Echoray 17:15, 30. Sep 2004 (CEST)

Zur letzten Änderung von Flominator (siehe Versionshistory).

• Independent ist imho nicht "Quatsch". Abhängig bedeutet, dass etwas ohne etwas anderem nicht mehr läuft. Unabhängig das Gegenteil. Und der Sinn eines RAIDS (ausgenommen Level 0) ist, dass sie nicht abhängig voneindern sind (IM BESCHRÄNKTEN RAHMEN NATÜRLICH!). So ist das zu verstehen und daher korrekt.
• Und eigentlich sekundär ob ein Begriff "Quatsch" ist oder nicht, ausschlaggebend ist wofür er steht. Sowohl die eine wie die andere Bezeichnung sind reine Marketingbegriffe. Es macht Null Sinn sich über einen Begriff zu streiten welche uns die Marketingabteilung vorgibt - es gäbe tausend andere Beispiele für sinnlose Produktebezeichnungen. Fakt ist nunmal, dass heute Independent weiterverbreitet ist als Inexpensive, siehe: [5] und [6]. Schön ist auch dieses Doku, als weiteres Beispiel welches beide Schreibweisen nochmal erklärt: [7].
• Bei alldem hättest du meine Änderungen vielleicht mal komplett ansehen sollen. Dann wäre dir aufgefallen, dass unter Abschnitt "Geschichte" genau dies nochmal erklärt wird. Deine einfache Änderung oben in der Einleitung führt zu einem total unlogischen Artikel der sich selber widerspricht.

Aus den obigen Gründen habe ich inexpensive/independend wieder rückgängig gemacht. Zudem entspricht es nun auch der Definition in der englischen Wikipedia. Jemand der RAID auf DE und EN nachschauen würde, müsste sich ja ansonsten fragen. Falls du nicht einverstanden bist, können wir und andere dies erst hier unter der Diskussion ausführlich besprechen. Den Rest deiner Änderung lasse ich natürlich --Nightwish62 13:57, 27. Jan 2005 (CET)

Thema Marketing: Nur weil man auf jedem zweiten Plakat Handy's liest, wird es grammatikalisch nicht richtiger. Die ursprüngliche Bedeutung ist und bleibt inexpensive! Gruß, Flominator 09:32, 15. Mär 2005 (CET)

inexpensive ist ein ganz normales englisches wort und auch richtig - das ganze ist ja als seitenhieb auf SLEDs gedacht (single large expensive disk) - redundant array of inexpensive disks wuerde frei uebersetzt ja etwas wie "ueberflüssige billige aneinandergereihte laufwerke" bzw "billige aneinandergereihte laufwerke mit reserve" - die wortschaffung bzw bezeichnungsschaffung ist etwa genauso sinnlos wie "ego-shooter" (ein scheinanglizismus) oder "hardware" und "software" (welche auch nur aus jux und tollerei entstanden sind) -- das steht aber eh schon im artikel, nur halt weiter unten bei "geschichte" - sollte man vielleicht weiter nach oben einreihen --suit Benutzer Diskussion:Suit 18:43, 13. Jul 2005 (CEST)

Wir beschreiben hier doch nicht vor allem, wie eine Bezeichnung ursprünglich war, sondern was sie heute bedeutet. Sprache entwickelt sich, auch beeinflusst von Marketing Abteilungen (ja man kann das doof finden). independent ist nicht flascher als inexpensive - so lange hier niemand eine gute Quelle nennt, derer nach die norminative Deutung dieser Abkürzung 2005 inexpensive ist. Kruemelmo 22:40, 8. Aug 2005 (CEST)

Bitte lasst eure Finger von INEXPENSIVE wenn es um das "alte", originale RAID geht. Ursprünglich hieß es nun mal INEXPENSIVE, da sich hier aus einer Anordnung von "billigen" Festplatten handelte, die die selbe Kapazität und Datensicherheit (oder sogar besser) erzeugen lies, wie es vorher nur mit extrem teuren "Superfestplatten" (Single Large Expensive Disks (SLED)) möglich war. HEUTE wird meist independent daraus gemacht, für heute ist indepent also richtig, aber das I im ursprünglichen RAID, bedeutet eben inexpensive und nur inexpensive! Quelle für alle Besserwisser ist ja unten im Artikel angehängt, aber hier noch einmal: http://www.cs.cmu.edu/~garth/RAIDpaper/Patterson88.pdf --WikiMax 15:36, 21. Jan 2006 (CET)

Einverstanden, aber: Die Änderung der IP war natürlich insofern konsequent, als "'A Case for Redundant Array of Independent Disks (RAID)' [...] (frei übersetzt: Redundant speichernder Verbund kostengünstiger Festplatten)." natürlich Unsinn war. --Eike 17:14, 21. Jan 2006 (CET)

Klar, die Änderung der IP war zwar falsch, aber in sich absolut schlüssig zum Text, also verständlich. In sofern (doppelten) Dank an die unbekannte IP (auch weil ich dadurch dies erst bemerkt habe). *bg* --WikiMax 18:22, 21. Jan 2006 (CET)

Raid 50

>>Ein RAID-50-Verbund wird bei Datenbanken verwendet, wo Redundanz und Schreibdurchsatz im Vordergrund stehen.<<

Der Aussage hoher Schreibdurchsatz stimme ich zu (Lesen und Schreiben gehen sehr schnell). Aber von einer Redundanz ist hier nichts zu erkennen. (Grafiklink: http://www.digiliant.com/images/tech_info/raid50.gif) Das mit der Redundanz trifft auf Raid 51 zu. (Raid 5 kombinert mit Raid 1 (Mirroring) (--Tobbac 11:04, 9. Mär. 2009 (CET))

RAID 5EE

Ich vermisse eine Quellenangabe zur Anmerkung, daß mittlerweile selbst IBM vom Einsatz von RAID 5EE abrät. Weiterhin - sofern es sich hierbei um einen Firmwarefehler handelt - ist davon auszugehen, daß dieser Fehler in neueren Firmwareversionen behoben wurde, womit die Information irreführend ist. Sollte dieser Absatz von daher nicht besser entfernt werden?

Schopi68 12:18, 11. Mär. 2009 (CET)

RAID 3 HW-Controller

Der Hersteller XFX hat vor mehr als 2 Jahren eine Karte auf dem Markt gebracht die eine Xor Einheit verbaut hat, und noch 64MB Speicher zur Verfügung stellt. Die Karte gab es mit 3 Port und eine Mac Version mit 5 Ports. Der Preis lag um die 35 Euro. Als Schnittstelle verfügte sie über 32Bit 33/66MHz PCI Steckplatz.

XFX Revo64 (nicht signierter Beitrag von 89.166.250.73 (Diskussion | Beiträge) 03:04, 11. Apr. 2009 (CEST))

Zur Beschreibung vom RAID1

>>> Zur Erhöhung der Leseleistung kann ein RAID-1-System beim Lesen auf mehr als eine Festplatte zugreifen und gleichzeitig verschiedene Sektoren von verschiedenen Platten einlesen.

NEIN, das geht nicht. Grund dafür ist die logische Pfad-Nutzung. Der logische Pfad auf die Platte kann nur einmal verwendet werden und nicht gleichzeitig mehrere Male. Das geht aus der Erlang-C Statistik für die Path-Utilization hervor. Wenn man also einen Request zur logischen RAID1-Disk schickt, dann werden beide physischen Platten angesprochen, aber es wird der Block von der physischen Disk gelesen, die als ERSTES den korrekten Block liefern kann.

>>> Bei einem System mit zwei Festplatten lässt sich so die Leistung verdoppeln.

NEIN, das ist statistisch ebenfalls ausgeschlossen. Man kann die Leistung maximal um 50% steigern, aber nicht um 100%. In der Realität liegt die Leistungverbesserung bei ca. 40%.

Kleiner Nachtrag - Ein bisschen Mathematik

Einzel-Disk - Charakteristik für lesenden Random-Zugriff

Seek Length = N/3 ; Rotationslatenz = R = T/2 ; Queue Depth = q = 3

RAID1-Disk - Charakteristik für lesenden Random-Zugriff:

Seek Length = N/5 ; Rotationslatenz = R = T/3 ; Queue Depth = Q = 6

mit N = Zylinderanzahl der Disk ; T = Zeit für eine Rotation

Der Queue Depth Vorteil vom RAID1 bezogen auf eine Einzel-Disk ergibt sich aus:

Queue Vorteil = 1/3*[1-sqrt(1+q)/sqrt(1+Q)] = 1/3*[1-sqrt(4)/sqrt(7)] = 0.08 => 8%

Man erhält somit aus den Differenzen folgenden Performance-Vorteil beim lesenden Random-Zugriff auf ein RAID1:

Seek Length Vorteil vom RAID1: 13%

Rotationslatenz Vorteil vom RAID1: 17%

Queue Depth Vorteil vom RAID1: 8%

Das macht in Summe 38% Performance-Vorteil beim lesenden Random-Zugriff auf ein RAID1. (nicht signierter Beitrag von 89.48.2.254 (Diskussion | Beiträge) 15:40, 18. Mai 2009 (CEST))

>>> Die Lesecharakteristik entspricht hierbei einem RAID-0-System.

NEIN, ist ebenfalls ausgeschlossen. Ein RAID1 hat eine kürzer Zugriffszeit, die sich aus dem statistischen System (Two-Head System) aus zwei gleichen Daten-Block aus zwei verschiedenen Platten ergibt. Ein RAID0 heißt ein Daten-Block auf einer Platte (One-Head System).

>>> Diese Funktion bieten aber nicht alle Controller oder Softwareimplementierungen an. Sie erhöht die Lese-Geschwindigkeit des Systems enorm, geht aber auf Kosten der Sicherheit (vergl. nächsten Absatz). Eine solche Implementierung schützt vor einem kompletten Datenträgerausfall, aber nicht vor Problemen mit fehlerhaften Sektoren, zumindest falls diese erst nach dem Speichern (read after write verify) auftreten.

NEIN, das ist auch nicht korrekt. Es wäre etwas sinnlos von Redundanz zusprechen, wenn fehlerhafte Sektoren (Bad Blocks) nicht erkannt werden (Das macht die Disk bzw. das RAID eigentlich automatisch). Zudem haben alle RAID1 Systeme (Software oder Hardware) einen "Mirror Write Consistency" Daten-Cache auf allen Platten im RAID. Damit wird gewährleistet, das ein Schreibvorgang erst als gültig gemeldet wird, wenn wirklich zwei Daten-Blöcke auf den beiden Disks korrekt geschrieben wurden.

>>> Zur Erhöhung der Sicherheit kann ein RAID-1-System beim Lesen stets auf mehr als eine Festplatte zugreifen (wenn die Antworten vorliegen, werden die beiden Datenströme verglichen, und bei Unstimmigkeiten wird eine Fehlermeldung ausgegeben, da die Spiegelung nicht länger besteht). Diese Funktion bieten nur wenige Controller an, auch reduziert sie die Geschwindigkeit des Systems geringfügig.

NEIN, das ist auch etwas fern der Realität. Die Sicherheit heißt 100% Redundanz. Wenn man auf einen gespiegelten Daten-Block zugreift, dann werden die Antworten nicht verglichen. Das kostet Zeit und würde ein RAID1 leistungsmäßig erheblich schwächen. Der Lese-Vorgang mit fehlerhaften Block wird wie folgt durchgeführt:

1. Logischer Request an die logische RAID1-Disk

2. Trennung der logischen Anfrage in zwei physische Anfragen

3. Überprüfung der Adressen im Mirror Write Consistency Cache der jeweiligen Disk => kein Fehler gefunden

4. 1.Platte liefert einen fehlerhaften Sektor/Block

5. Markierung vom fehlerhaften Sektor/Block im Mirror Write Consistency Cache

6. 2.Platte liefert einen korrekten Sektor/Block

7. Meldung im System über "Stale Partition" = Spiegelung nicht mehr intakt

8. Auslieferung vom korrekten Sektor/Block an das System

Würde jetzt die zweite Platte auch einen fehlerhaften Sektor/Block melden, würde das RAID1 die Redundanz verloren haben. Damit geht das RAID1 in den Status "offline". Manche Systeme ermöglichen trotz ausgefallender Redundanz, noch einen lesenden Zugriff.

Gruß WoKi (nicht signierter Beitrag von 89.48.53.31 (Diskussion | Beiträge) 03:22, 3. Mai 2009 (CEST))

RAID 6

Im Artikel steht: "Der Performance-Malus bei Schreiboperationen (Write Penalty) ist bei RAID 6 etwas größer als bei RAID 5". Mir leuchtet nicht ein, warum es bei einer Hardware-Implementierung da einen größeren Penalty geben sollte - parallel berechnet, paralleler Zugriff, was sollte da langsamer sein? Und warum? -- 92.204.66.128 12:56, 19. Jun. 2009 (CEST)

und die zwei Antworten:

  1. Write Hole/Penalty

  2. Inter I/O Parallelität

>>> Zur Antwort 1) Write Hole/Penalty

1. Die zwei oder drei Blöcke können parallel gelesen werden

2. aber schreiben kann man die Blöcke nur versetzt nacheinander

+ Daten-Block schreiben -> OKAY

+ dann 1.Parity schreiben -> OKAY

+ danach 2.Parity schreiben -> OKAY -> Gesamt-Schreibauftrag erfolgreich

Die Parity ist die Redundanz-Information (Summen-Information) der kompletten Stripe und nicht für den einzelnen Daten-Block. Also muss zuerst der Daten-Block geschrieben werden, bevor die Summen-Information geschrieben werden kann. Wenn der Daten-Block geschrieben ist, dann hat man einen Redundanz-Verlust "Write Hole" für die Zeit, in der die Parity-Information geschrieben wird.

Aus der Summe der Einzel-Zugriffe im Read-Modify-Write Mechanismus ergibt sich für den Gesamt-Schreibauftrag eine Zugriffszeit T(W) rein statistisch von:

RAID5 : T(W) = 2*t(RMW)

RAID6 : T(W) = 3*t(RMW)

Somit hat man also eine Erklärung, wieso ein Random-schreibender Auftrag beim RAID6 gegenüber eines RAID5 "langsamer" ist.

Die Write-Penalty bezeichnet den zeitlichen Unterschied eines logischen Schreibauftrags zu den physisch notwendigen I/O-Aufträgen.

DISK : 1 logischer Write = 1 physischer I/O = 1*Write

RAID1: 1 logischer Write = 2 physische I/Os = 2*Write

RAID5: 1 logischer Write = 4 physische I/Os = 2*(Read+Write)

RAID6: 1 logischer Write = 6 physische I/Os = 3*(Read+Write)

>>> Zur Antwort 2) Inter I/O Parallelität

Mal ein Beispiel: RAID5(6+P) Vergleich mit RAID6(5+P+Q)

Um es vergleichen zu können, muss die Gesamt-Disk-Anzahl gleich sein.

Jetzt ist die Inter I/O Parallelität (auch Auftrags-Parallelität genannt) für die Gesamt-Anzahl an Random-schreibenden Aufträgen vom Bedeutung. Die Wahrscheinlichkeit, dass sich pro Gesamt-Schreibauftrag zwei bzw. drei Sub-Zugriffe parallel auf einen Verbund von Platten abspielen können, hängt davon ab, wie wahrscheinlich diese zwei bzw. drei parallelen Sub-Zugriffe innerhalb des Verbundes sind.

RAID5: Gesamt-Schreibauftrag = 2 Disks notwendig

RAID6: Gesamt-Schreibauftrag = 3 Disks notwendig

Wenn man also die Wahrscheinlichkeit von Gesamt-Schreibauftrag mit 2 Disks bzw. 3 Disks (Inter I/O Parallelität) auf die Gesamt-Anzahl der im Verbund verfügbaren Disks berechnet, dann erhält man für die Anzahl an parallelen Random-schreibenden Gesamt-Aufträgen:

Inter I/O Parallelität RAID5(6+P) = 1,63 (Statistische Parallelität)

Inter I/O Parallelität RAID6(5+P+Q) = 1,11 (Statistische Parallelität)

Wenn man jetzt noch Caching- und Queuing-Effekte mit in die Berechnung einbezieht, dann ergibt sich:

Inter I/O Parallelität RAID5(6+P) = 2,3 (Zeitliche Parallelität)

Inter I/O Parallelität RAID6(5+P+Q) = 1,6 (Zeitliche Parallelität)

Somit hat man also eine Erklärung, weshalb ein RAID6 gegenüber eines RAID5 im Random-schreibenden Zugriff "langsamer" ist.

In einer Zeiteinheit kann also ein RAID5 rund 2,3 und ein RAID6 rund 1,6 parallele Random-schreibende Gesamt-Aufträge mit dem Read-Modify-Write Mechanismus durchführen, wenn die Randbedingungen gleich sind.

Wenn man die IOPS = I/O Operationen pro Sekunde auf das jeweilige RAID-System berechnet, und definieren wir mal, das im RMW-Modus ein RAID5 ca. 50 IOPS und ein RAID6 ca. 30 IOPS pro Gesamt-Schreibauftrag schafft, dann ergibt sich:

IOPS (pro RAID5) = Inter I/O Parallelität * IOPS = 2,3 * 50 = 115

IOPS (pro RAID6) = Inter I/O Parallelität * IOPS = 1,6 * 30 = 48

Man sieht also, dass ein RAID6 eine sehr schlechte Random-Write-Performance hat. Auch wenn die IOPS für RAID5 und RAID6 gleich wären (was sie definitiv nicht sind), dann würde das RAID6 trotzdem schlechter abschneiden, weil die Inter I/O Parallelität geringer ausfällt.

Beim Random-lesenden Zugriff haben beide RAIDs den gleichen Wert der Inter I/O Paralellität:

Inter I/O Parallelität RAID5(6+P) = RAID6(5+P+Q) = 4 (Statistische Parallelität)

Inter I/O Parallelität RAID5(6+P) = RAID6(5+P+Q) = 5,6 (Zeitliche Parallelität)

Damit wird man beim Random-lesenden Zugriff keinen Unterschied finden.

Und, alles verstanden?

Gruß WoKi (nicht signierter Beitrag von 89.60.246.78 (Diskussion | Beiträge) 18:27, 21. Jun. 2009 (CEST))

Raid 7

Auch das proprietäre RAID 7 ist ähnlich wie RAID 5 aufgebaut. Allerdings setzt der Hersteller Storage Computer im Controller zusätzlich ein lokales Echtzeitbetriebssystem ein. Schnelle Datenbusse und mehrere große Pufferspeicher koppeln die Laufwerke vom Bus ab. Dieses asynchrone Verfahren soll Lese- wie Schreiboperationen gegenüber anderen RAID-Varianten erheblich beschleunigen. Zudem lässt sich, ähnlich wie bei RAID 6, die Paritätsinformation auch auf mehrere Laufwerke speichern. (nicht signierter Beitrag von 89.166.184.208 (Diskussion | Beiträge) 18:01, 21. Jul 2009 (CEST))

Host based RAID

Der Hinweis unter Hardware-RAID, bezüglich des Host based Raid, gehört unter den Titel Software-RAID. Quelle: http://www.gigabyte.de/FileList/FAQ/old_networking_faq/intel_sata_raid_userguide.pdf (nicht signierter Beitrag von 91.97.158.225 (Diskussion | Beiträge) 13:19, 27. Jul 2009 (CEST))

>>> Unterscheidung: Hardware RAID - Software RAID

Heute gibt es prinzipiell drei verschiedene Methoden für die Virtualisierung von Storage-Systemen. Diese unterscheiden sich darin, auf welcher Ebene die Virtualisierung durchgeführt wird. Es gibt folgende Moglichkeiten:

+ Virtualisierung auf Server/Host-Ebene (Virtual I/O Server, Logical Volume Manager, Software RAID)

+ Virtualisierung auf Netzwerk-Ebene (Appliance, SAN Volume Controller)

+ Virtualisierung auf Device/Subsystem-Ebene (Hardware RAID, Disk Array)

Bei der Storage-Virtualisierung sind immer drei Fragen zu beantworten:

1. WAS wird virtualisiert? - Block, Disk, Filesystem, File

2. WER virtualisiert? - Server/Host, Device/Subsystem, Netzwerk

3. WIE wird virtualisiert? - Symmetrisch (im Daten-Pfad), Asymmetrisch (außerhalb Daten-Pfad)

Machine Layers:

    Upper   Applications
            Operating System
            File System
            Volume Management  <- Hier setzt ein Software RAID an
            Device Driver
    Lower   Device/Subsystem   <- Hier setzt ein Hardware RAID an

Bei den Hardware RAIDs gibt es jetzt noch die Unterscheidung zwischen dem Host-basisierenden RAID (RAID-Adapter) und dem RAID Subsystem - Disk Array. Das Host-basisierenden RAID heißt deshalb so, weil sich der RAID-Adapter auf der Host-Seite befindet. Auch die RAID-Adminstration wird auf der Host-Seite durchgeführt.

Im Endergebnis unterscheiden sich diese beiden Varianten jedoch nicht, da der Server/Host bzw. die nächste Ebene der Device-Driver immer nur das "zusammengebaute" Device erkennt und ansprechen kann.

Gruß Woki (nicht signierter Beitrag von 89.48.9.62 (Diskussion | Beiträge) 01:39, 10. Aug. 2009 (CEST))

RAID => Erhöhung der Datensicherheit oder nur Datenverfügbarkeit?

In Anspielung auf die Einleitung, wo steht:

"Ein RAID-System dient zur Organisation mehrerer physischer Festplatten eines Computers zu einem logischen Laufwerk, das eine höhere Datensicherheit bei Ausfall einzelner Festplatten und/oder einen größeren Datendurchsatz erlaubt als ein einzelnes physisches Laufwerk."

Wird wirklich die Datensicherheit erhöht? M.E. gewährleistet man nur die Datenverügbarkeit -- wenn einem ein Virus oder ein DAU das System zerschießt, dann sind alle/einige Daten auf allen Platten futsch und wäre auf ein *Backup* angewiesen.

Man hat halt den Vorteil, dass wenn einem eine Festplatte des RAIDs abrauscht, man weiterhin sein System nutzen kann, ohne erst ein Backup einspielen zu müssen. Backups sind aber nach wie vor wichtig. Insofern finde ich den Artikel in der Hinsicht irreführend.

Wenn kein Einspruch erfolgt, werde ich den Artikel dahingehend ändern:

RAID0 => Erhöhung des Datendurchsatz RAID1 und ähnliche => Erhöhung der Datenverfügbarkeit Backup => Erhöhung der Datensicherheit

und es gibt mehrere Konzepte, die das alles kombinieren.

--Wolle212 15:53, 31. Aug. 2009 (CEST)

http://de.wikipedia.org/wiki/Backup#RAID_1 Da stehts eben so. Ich werde es also anpassen. --Wolle212 15:56, 31. Aug. 2009 (CEST)

Kleine Anmerkung

"Wird wirklich die Datensicherheit erhöht? M.E. gewährleistet man nur die Datenverfügbarkeit

Wenn einem ein Virus oder ein DAU das System zerschießt, dann sind alle/einige Daten auf

allen Platten futsch und wäre auf ein *Backup* angewiesen."

Aber hat ein Backup mit Datensicherheit zu tun. Ganz streng genommen - NEIN - Ein Backup

gewährleistet eine passive Datenverfügbarkeit, aber keine Datensicherheit in bezug auf

die Daten selbst.

Wenn zum Beispiel, der Virus bereits auf den Backup-Medium ist, dann nutzt das Backup

auch nichts. Man kann die Daten ja auch auf dem Backup-Medium manipulieren.

Vor menschlichen Fehlern schützt kein einziges System, wenn man die nötigen Rechte und

Berechtigungen hat, kann man jedes System in den Abgrund reißen.

Das aktive Daten-System wird durch das RAID geschützt z.B. durch die Redundanz-Informationen

innerhalb des Disk-Verbundes. Schutz hat aber immer etwas mit Sicherheit zu tun.

Trotzdem es ist schon richtig, dass ein RAID nichts mit Datensicherheit

(Schutz der Informationen) im eigentlichen Sinne zu tun hat, sondern mit der

Sicherheit vom aktiven Daten-System.

Gruß WoKi

PS.: Die genauere Klassifizierung findet man unter den Begriff: "EDAP – Extended Data Availability and Protection"

Unterscheidung von 3 verschiedene Stufen der Verfügbarkeit für Speicherplattensystemen

und Speichersubsysteme durch 21 Kriterien:

1. EDAP: Failure Resistant – gegen Fehler geschützt

2. EDAP: Failure Tolerant – kann Fehler korrigieren

3. EDAP: Disaster Tolerant – übersteht selbst Katastrophen

Die Unterteilung wurde vom RAB - RAID Advisory Board durchgeführt. (nicht signierter Beitrag von 89.48.10.7 (Diskussion | Beiträge) 02:20, 1. Sep. 2009 (CEST))

Vorteile/Nachteile von HM/SW-Raid

es wäre vielleicht sinnvoll, darauf hinzuweisen, das es bei einem Software-Raid zu Datenverlust kommen kann (auch bei Raid 1), wenn das Betriebssystem bzw. der Treiber nicht richtig funktionieren. Bei einem Festplattenausfall hat man außerdem bei einem Hardware-Raid weniger Probleme/Arbeit als bei einem Software-Raid. Im Artikel gewinnt man den Eindruck, das Software-Raid besser ist als Hardware-Raid. Ich würde ein Software-Raid nie auf einem Storage-Server einsetzen, egal ob es schneller ist oder nicht. -- Ifak 09:44, 8. Jul. 2009 (CEST)

meine Erfahrungen decken sich nicht mit deinen Eindrücken. Ein defekter Prozessor auf einem Hardware-RAID-Controller kann auch zu Datenverlust führen, ein defekter Controller mit proprietärem Chipsatz kann, sollte er bei defekt nicht ersetzt werden können, auch dazu führen, dass man nicht mehr auf die Daten zugreifen kann. Ebenso kann ein defektes Dateisystem zu Datenverlusten führen, auch wenn ein Hardware-RAID perfekt funktioniert. Ich verstehe nicht worauf du hinaus willst - du beschreibst irgendwelche Eventualitäten. Wenn du deine Aussagen mit Quellen untermauern kannst, lässt sich das natürlich im Artikel einbauen --suit Benutzer Diskussion:Suit 23:02, 8. Jul. 2009 (CEST)

ok, ein Raid-Controller ist mir bisher noch nicht abgeraucht. Aber wenn SW-Raid doch so "gut" ist, wo macht ein HW-Raid dann überhaupt noch Sinn oder macht es überhaupt noch Sinn? Das mit dem defekten Controller kann ich quasi ausschliessen in dem ich mir einen in mein Lager packe. Mit Festplatten mache ich das inzwischen, da ich ja nicht erst losrennen will wenn es zu spät ist. Ein Vergleich, welches Raid-System für welche Anwendung geeignet ist wäre praktisch. -- Ifak 14:39, 21. Jul. 2009 (CEST)

Ein reines Software-RAID ist nicht weniger robust als ein Hardware-RAID, eher im Gegenteil. Es hat außerdem den Vorteil, dass es nicht vom Controller abhängig ist. Bei einem Ausfall des Controllers kann der einfach durch einen anderen ersetzt werden. Nachteil ist, dass unter Umständen mehr Daten durch den Bus müssen. Bei einem RAID-1 z.B. müssen die gleichen Daten doppelt von der CPU durch den Systembus über den Controller zu beiden Platten geschrieben werden, wohingegen ein Hardware-RAID-1 die Daten nur einmal am Controller erhält und von da aus jeweils auf beide Platten schreibt, was keine Beeinträchtigung gegenüber einer einzelnen Nicht-RAID-Platte ist wenn die beiden Platten des RAID-1 an verscheidenen Channels angebunden sind (betrifft nur IDE/SCSI, bei SATA eh fast immer der Fall). (nicht signierter Beitrag von X4u (Diskussion | Beiträge) 23:48, 23. Sep. 2009 (CEST))

Statistische Fehlerrate bei großen Arrays

--Mathias 03:50, 28. Sep. 2009 (CEST):Hey, nun lass uns das Thema "Große Platten" mal hier diskutieren, anstatt ständig im Artikel rumzupfuschen... Wir sind uns doch wohl einig, dass das Problem an den TB-großen RAID-Arrays liegt.

Nein! solche Arrays gibt es schon seit langem , z.B. von emc2 oder IBM - die funktionieren und haben mit der Fehlerwahrscheinlichkeit kein Problem. (Die nutzen aber auch kein RAID 5 sondern "überlisten" die Wahrscheinlichkeit durch RAID-Kombinationen, die analog zu RAID 2 oder wie RAID 50 arbeiten) Das Problem liegt an den Platten und deren Grö0e, im Verhältnis zur Fehlerwahrscheinlichkeit - die mit steigender Größe nun mal zunehmend zum reellen Problem wird - übrigens auch wenn man sie nicht im RAID nutzt.--Nmoas 12:30, 28. Sep. 2009 (CEST)

IBM wird aber auch keine Consumerplatten nutzen, von daher... ;)

SATA gibts aber schon.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Und?!--Mathias 19:28, 1. Okt. 2009 (CEST)

Was und?--Nmoas 20:21, 4. Okt. 2009 (CEST)

Was du damit sagen willst? So schwer war die Fragestellung jetzt nicht...--Mathias 15:45, 9. Okt. 2009 (CEST)

RAID50 kann gutgehen, aber wenn der Lesefehler im ohnehin beschädigten Stripe passiert? Glücksspiel ist bei solchen Konfigurationen schon irgendwie fehl am Platze. Ausfälle passieren zufällig, darum ist es zwar schön, dass in jedem Leg eine Platte schlapp machen kann, aber zwei Ausfälle können ebenso dazu führen, dass alles hinüber ist.

Das nennt man einen Doppelfehler, der ist von den dem RAID 5 Level eben nicht abgedeckt - auch nicht von RAID 5 über 26 Platten. Dazu bieten die Hersteller RAID 6 und RAID 60. Die nicht-Glücksspiel Serien EMC Symmetrix fahren ihre bis zu 2400 Laufwerken (auch SATA! mit 1TB) in 3+1 und 7+1 RAID 5 Sets oder in 6+2 und 14+2 RAID 6 Sets (Bei 2400 Stück 1 TB Platten und 14+2 Raid 6 stehen netto noch rund 2000 TB zur Verfügung).--Nmoas 21:08, 28. Sep. 2009 (CEST)

Naja dann zieht das Argument RAID50 aber auch nicht mehr, sondern es sind grundsätzlich RAID6 für die Stripes nötig?--Mathias 19:28, 1. Okt. 2009 (CEST)

Was haben doppelfehler auf einmal bei dieser Fragestellung zu suchen, das ist sicher ein interessantes, aber separates Thema.--Nmoas 20:21, 4. Okt. 2009 (CEST)

Das Thema RAID50 hast du eingebracht, nicht ich. --Mathias 15:45, 9. Okt. 2009 (CEST)

In RAID2 muss ich mich erst mal reindenken, da hab ich grad keine Zeit für. --Mathias 17:20, 28. Sep. 2009 (CEST)

Ist nicht so relevant, da auch nicht weit verbreitet, bietet aber je nach Implementierung eine Fehlererkennung für Einzelfehler so wie eine Fehlerkorrektur für Einzelfehler. Weit interessanter als RAID 2: Fehlerkorrekturverfahren.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Für deren Rebuild müssen x TB gelesen werden, und der Rebuild klappt nur, wenn ausnahmslos jedes Bit daraus korrekt gelesen werden kann. Die Fehlerrate von 10^-14 macht dem mit steigender Größe immer häufiger einen Strich durch die Rechnung. Soweit okay?

Ja vor allem bei RAID 5 ist das ein großes Problem - bei RAID 50 ist das allerdings ein weit aus kleineres Problem, da hier ja nicht(!) jedesmal alle Platten eingelesen werden.--Nmoas 12:30, 28. Sep. 2009 (CEST)

Das ist wohl richtig. Je feiner das 0-Stripe, desto weniger. Macht nur in der praktischen Umsetzung Probleme, da jede zusätzliche Platte Platz, Strom, Kabel und einen Controllerport braucht. Aber in der Theorie kann ich denke ich mal zustimmen. --Mathias 17:20, 28. Sep. 2009 (CEST)

Das ist bei Profisystemen die gängige Praxis - das Kabelproblem sollte aber auch schon bei kleinen Systemen ein solider Drive-Cage mit Backplane lösen - sonst wirds auch nix mit HotPlug usw...--Nmoas 21:08, 28. Sep. 2009 (CEST)

Da würd mich direkt interessieren, wo bei dir ein "kleines" System anfängt. --Mathias 19:28, 1. Okt. 2009 (CEST)

Bei allen Systemen mit RAID...--Nmoas 20:21, 4. Okt. 2009 (CEST)

Klar, Backplane und Hotplug bei RAID1. Sind wir wieder beim Punkt "ohne riesengroßes Budget darfst du gar nicht anfangen"?--Mathias 15:45, 9. Okt. 2009 (CEST)

Dann sag ich: Es ist sch***egal, wie dieser Platz zusammenkommt.

Nein, genau das ist Dein Problem! Intelligentere RAID Level wie RAID 50 (auch andere kombinierte RAID Level) entschärfen das Problem, RAID 1 und RAID 2 kennen es so auch gar nicht.--Nmoas 12:30, 28. Sep. 2009 (CEST)

Das ist schön und gut, aber im Artikel geht es nunmal um RAID5 in Verbindung mit Consumerplatten. Welcher Privat-/SOHO-Nutzer hat ein RAID6, 50 oder 1 mit 3+ Platten? --Mathias 17:20, 28. Sep. 2009 (CEST)

NEIN!!!! es geht in diesem Absatz des WIKI-Artikel RAID um Probleme die erst jetzt - da es so große Platten gibt - auftreten. WIKI ist nicht speziell auf Privat-/SOHO ausgerichtet. ZFS und damit RAID-Z2 (~RAID 6) ist übrigens gar nicht so selten - auch im SOHO Bereich.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Hab ich auch nie behauptet. Aber Wikipedia sollte dem unkundigen Leser nicht schon im Geplänkel vor einem an sich wichtigen Artikel weismachen, dass man ohne mindestens 4 Festplatten eigentlich gar nicht mit dem Speichern von Daten anfangen dürfte. --Mathias 19:28, 1. Okt. 2009 (CEST)

Wenn man in den Terra Byte Bereich vordringt, JA. Hobbyisten sollten ja auch gewarnt sein, oder eben RAID Level wie 1 oder 10 benutzen.--Nmoas 20:21, 4. Okt. 2009 (CEST)

Seh ich das grade richtig, du ziehst ständig EMC-Systeme mit abartiger Leistung und Preis-Leistung heran, bist aber unfähig Terabyte richtig zu schreiben?--Mathias 15:45, 9. Okt. 2009 (CEST)

Ob nun (jeweils RAID5-Konfiguration, Platten mit identischer, zeitlich konstanter Fehlerrate, ansonsten ideal funktionierende Komponenten und Sinn/Unsinn der Konfigurationen vernachlässigt) 3*2000GB an nem onboard-Controller oder 26*160GB an nem 1000-Euro-PCIe x8-Prachtstück hängen, ist ne reine Kosten-/Raum-/Nutzungsfrage und unabhängig von der Auswahlwahrscheinlichkeit. Beides liefert effektiv 4TB Nutzkapazität. Fällt Konfig 1 aus, müssen 2 Platten jeweils 2TB auslesen. Fällt Konfig 2 aus, müssen 25 Platten je 160 GB auslesen. Kommt vom Aufwand her aufs gleiche raus. Es ist zwar (deutlich) wahrscheinlicher, dass eine 160er den Vorgang fehlerfrei packt, allerdings müssen 24 andere das ebenfalls schaffen, was den Vorteil komplett aufhebt. Wo ist nun der Malus für das System mit "großen Platten"?

Genau da liegt wieder Dein Problem, denn da ist ein Malus für große Platten. Ich kann aus 3 Stück zu je 2 TB eben noch keinen RAID 50 Verbund bauen (minimum 6 Platten). Auch einRAID 10 bräuchte 4 Platten. Aus 26 Stück zu je 160 GB lassen sich hingegen problemlos bis zu 8 RAID 5 Sets aus 3 Platten bilden oder auch zwei Sets mit je 13 Platten, wie auch immer, ich muss beim Austausch einer Platte nie alle intakten 25 Platten (im ersten Fall zwei und im zweiten Fall 12) einlesen. Im Zusammenhang mit ZFS (teilweise bei Sun, teilweise bei Nexenta) gibt es hierüber einige gute Artikel zu googeln. Auch ist das IOPS Verhalten von Arrays aus wenigen Platten miserabel - aber das ist eine ganz andere Frage.--Nmoas 12:30, 28. Sep. 2009 (CEST)

siehe oben - und Sinn/Unsinn der Configs hab ich ja bewusst ausgeklammert.

Es ist ein Problem was neuerdings bei den aktuellen Plattengroßen leicht auftreten kann - besonders wenn Nicht-Profis werkeln. Es liegt nicht(!) unabdingbar an der Arraygröße - Profis die sich der Problematik bewisst sind werden die Statistik durch geeignetere RAID Konfigurationen (RAID 2, RAID 50, RAID Z) "überlisten", Laien hingegen laufen in offene Messer. Es liegt wie gesagt eben nicht an der Arraygröße, sondern an der Art wie der Array zusammengestellt wird, an der Fehlerwahrscheinlichkeit der einzelnen Platten und auch an deren Größe, durch die auf einmal auch Laien in den Terra Byte Bereich vordringen. Häufig wird eine preisgünstige Variante gesucht - die Folge: es wird mit wenigen aber dafür riesigen Platten gearbeitet „Schnäppchenpreis“ - und schwups wird die Plattengröße genau jetzt zum Problem. Mit kleineren Platten und etwas Nachdenken (z.B. RAID 60) wäre das nicht passiert.--Nmoas 12:30, 28. Sep. 2009 (CEST)

Naja, du wiederholst dich ;)

Nur ein Beispiel aus dem echten Leben... --Nmoas 21:08, 28. Sep. 2009 (CEST)

Wenn ich als 0815-Anwender dermaßen viele (alte) Platten hab

Dann hat man wohl auch keine TB Platten und somit das ganze Problem nicht.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Sehr gut. --Mathias 19:28, 1. Okt. 2009 (CEST)

und mir einen großen Controller dazu leiste, werd ich eher ein RAID5 anlegen als mir großartig Gedanken über verschachtelte RAID-Level zu machen. Zonk.

Das ist genau das Problem, bei großen Platten laufen gerade wenig versierte Admins Gefahr einen möglicherweise fatalen Konstruktionsfehler zu begehen. Und dann kommt der ZONK, der gemeiner Weise erst bei einem Störfall auftritt - wenn die Nerven eh schon blank liegen.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Das sag ich doch die ganze Zeit?!--Mathias 19:28, 1. Okt. 2009 (CEST)

Was widersprichst Du denn dauernd und revidierst Meine Aussagen, wenn Du doch meiner Meinung bist?!--Nmoas 20:21, 4. Okt. 2009 (CEST)

Du liest schon meine Aussagen, oder einfach nur den Text Wort für Wort?--Mathias 15:45, 9. Okt. 2009 (CEST)

Wenns hoch kommt ein RAID6, was ja an sich ja funktionieren sollte (oder?), nur einen Performance-Malus hat.

Robin Harris beschreibt warum RAID 6 ebenfalls nicht gegen solche statistischen Fehler geschützt ist.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Er sagt, dass RAID6 morgen wegen den UREs die selbe Sicherheit bietet wie heute RAID5. Logisch, da durch einen Fehler eine weitere Platte verheizt wird, und somit ein weiterer Paritätssatz nötig wird. Übermorgen lassen wir mal beiseite. Das wird eh nicht mehr mit Platten klappen, und über Fehler von SSDs hab ich keine Daten parat. --Mathias 19:28, 1. Okt. 2009 (CEST)

Mal sehen--Nmoas 20:21, 4. Okt. 2009 (CEST)

Es grüßt der Superparamagnetische Effekt. --Mathias 15:45, 9. Okt. 2009 (CEST)

Das sieht dann aber für die Userschicht unnötig aus, da man ja bereits Sicherheit durch einen Paritätssatz bei RAID5 hat.

Profis und User prallen oft aneinander, besonders in technischen Bereichen kann das fatale Folgen haben - wohl dem der sich gegen gut gemeinte User-Ratschläge absichert und diese Protokolliert und Gegenzeichnen lässt. An Schluss ist aber eh der Profi Schuld, der es ja hätte wissen müssen.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Da brauch ich gar nicht zu widersprechen --Mathias 19:28, 1. Okt. 2009 (CEST)

Wenn ich dagegen nur große Platten hab, kanns zum einen sein, dass z.B. ein 50 gar nicht möglich ist. Zum anderen ist das die derzeit günstigste Variante, wie du schon sagst (und außerdem "green"), sodass mir auch noch der passende Controller fehlen kann, dessen Gegenwert ein bis zwei weitere 1,5TB-Platten darstellt.

Zum einen kann man ja einfach die Platten spiegeln, das halte ich für den SOHO Bereich eh für am praktikabelsten. Falls es mal echte Probleme gibt, z.B. verursacht durch einen Netzteildefekt, hat man bei der Spiegelung noch die größten Chancen Daten zu retten. Das Striping bei RAID 5 kann leicht zum echten Problem werden - schnell ist der Raid-Verbund dann nicht mehr herstellbar. --Nmoas 21:08, 28. Sep. 2009 (CEST)

Davon abgesehen, dass 50% Kapazitätsverlust weh tun: Ja.--Mathias 19:28, 1. Okt. 2009 (CEST)

Bei 0,06 Euro pro Gigabyte tut es eigentlich nicht weh - wenn man mal an einen Datenverlust denkt, erst recht nicht.--Nmoas 20:21, 4. Okt. 2009 (CEST)

Vielleicht gehts dir ja anders, aber für mich sind bei einem 1TB-Array 60 Euro "Haben" oder eben nicht haben ein Unterschied. In EMC-Sphären sind das natürlich Peanuts und gehen schon für den Anlaufstrom drauf, ich weiß. --Mathias 15:45, 9. Okt. 2009 (CEST)

Oder: Go 4 OpenSolaris (oder Nexenta), RAID 0, RAID 1, RAID 5, RAID 6, RAID 50 und RAID 60 das alles ist beim ZFS gratis mit dabei. Nexenta hat sogar eine web-gesteuerte Appliance namens NexentaStor verfügbar.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Dann bring mal einen 2-Jahre-Windows-Vista-Klickibunti-User auf Solaris rüber, und wenns nur für die Überwachung eines kleinen Servers in der Abstellkammer ist. Viel Spaß --Mathias 19:28, 1. Okt. 2009 (CEST)

Deswegen hab ich auch auf NexentaStor hingewiesen, bis 2TB Kostenlos und Klickibunti, bei 4TB netto liegen die Lizenzkosten mit Support bei ca. 1000 Euro, also auch nicht sooo teuer, verglichen zu HPs Lefthand oder zu einem SAN-Array.--Nmoas 20:21, 4. Okt. 2009 (CEST)

1000 Euro Lizenzkosten bei 250 Euro Plattenkosten? Wieviele Jahre 24/7-Support will man damit verkaufen?--Mathias 15:45, 9. Okt. 2009 (CEST)

Insofern liegt das Problem ja primär an der Preisgestaltung der großen Platten und dem Kostendruck bei Privatanwendern. Wenn ich schon die billigsten Platten nehme, leiste ich mir auch keinen anständigen Controller (onboard-RAIDs machen maximal 0,1,5,10 und 01 mit) und werd auch nicht 50% Platz verschenken, indem ich RAID1, 10 oder 01 einsetze. RAID5 sieht dann aus wie das Allheilmittel, und genau hier hab ich (bzw. auch der Artikel) ja angesetzt.

Eben: RAID 5 ist nicht alles, der Artikel beschreibt RAID im Allgemeinen. Gerade heute, mit den großen 2 TB SATA Platten, bergen aber weniger die kleinen RAID 5 Systemen (mit 3 Platten), sondern bei mittelgroße Systemen mit 8 Platten - Dein Beispiel - ein latentes, konstruktionsbedingtes Risiko, mit ihrem Gelingfaktor von nur 1 zu 3. --Nmoas 21:08, 28. Sep. 2009 (CEST)

Das gibt ab gewisser Größe einfach Probleme, und das unabhängig davon, wie genau das Array zusammengesetzt ist.

Nein EMC skaliert mit RAIID 50 und RAID 60 auf bis 2400 Laufwerke mit netto 2 PetaByte pro EMC Symmetrix V-max Einzel-System. Man kann auch gleich mehrere davon haben und diese auch noch mit EMC Symmetrix Remote Data Facility (SRDF) spiegeln. --Nmoas 21:08, 28. Sep. 2009 (CEST)

Das war wieder auf RAID5 bezogen, welches im vorigen Satz auch drankam (danke fürs Zerpflücken). In Zukunft markier ich Stellen, auf die du dich dann stürzen darfst...--Mathias 19:28, 1. Okt. 2009 (CEST)

Ich kommentiere Deinen Text, genau dort wo was geschrieben steht. Einen Aufsatz schreibe ich nicht.--Nmoas 20:21, 4. Okt. 2009 (CEST)

Wie schon vermutet, du liest scheinbar Wort für Wort. Sinnzusammenhänge auseinanderreißen kann ich auch, nur bringt das niemanden vorwärts. --Mathias 15:45, 9. Okt. 2009 (CEST)

Dass das Problem bei echten wirtschaftlichen Interessen an der Verfügbarkeit der Daten anders angegangen wird und durch die sorgfältige Planung ausgehebelt werden kann, darüber sind wir uns ja einig?

100%--Nmoas 21:08, 28. Sep. 2009 (CEST)

Das kann man sicher auch beschreiben, aber für den professionellen Nutzer wird die Wikipedia nicht die wichtigste Informationsquelle sein. --Mathias 17:20, 28. Sep. 2009 (CEST)

Sehe ich nicht so, für manchen Entscheider (= nicht-Profi) ist WIKI mitunter schon eine Quelle. Und gerade unsere semiprofessionellen Admins neigen dazu WIKI zu lesen während sie gerade dabei sind 8 Platten mit 2 TB im Rocket-RAID-5 zusammen zu nageln. Und nach einiger Zeit wundern sich die Selben dann über statistische Sachverhalte und werden sich ärgern müssen.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Rocket-RAID...wo ist der lolwech-Smiley, wenn man ihn mal braucht?--Mathias 19:28, 1. Okt. 2009 (CEST)

ACK--Nmoas 20:21, 4. Okt. 2009 (CEST)

Eins noch, aber das ist themafremd: Achte bei deinen Edits doch mal auf Deppenleerzeichen, das stört wahnsinnig den Lesefluss:

"Für Consumer Laufwerke bedeutet das, dass es bei der Verarbeitung von etwa 16 Terabyte mit hoher Wahrscheinlichkeit zu einem Lesefehler kommt"

Sorry aber ich sehe das selbst leider nicht gescheit (Brille).--Nmoas 21:08, 28. Sep. 2009 (CEST)

Der Optiker deines Vertrauens berät dich gerne ;)

Ansonsten, mir fällt leider kein blödes Wortspiel für Consumer und Lauwerke ein. Aber vielleicht klappts mit den beiden Merkhilfen: Einmal für die Porsche-Fahrer unter uns: Die neuen 911 Modelle != Die neuen 911-Modelle. Und dann für die Naschkatzen: tinyurl.com/ yaj9qt2 (Werden auch Sie zum Pudding!)--Mathias 19:28, 1. Okt. 2009 (CEST)

Wobei, diese 16TB hätt ich gern mal begründet. Warum 16, und was ist eine "hohe" Wahrscheinlichkeit? Wenn du dem Normaluser nested RAIDs aufdrückst, dann sind dafür auch Zahlenbelege fällig, finde ich.--Mathias 17:20, 28. Sep. 2009 (CEST)

Das ist Dein Beispiel, Du kommst auf einen Fehler von 33 zu 100 bei 8 Platten - 8 x 2 ist 16 also 16TB. Wie kommst Du eigentlich auf 33 zu 100 - Zahlen hatte ich mir verkniffen, da ich die rechnerische Herleitung nicht wirklich beherrsche. Daher stammt von mir der Ausdruck eine "hohe" Wahrscheinlichkeit was Du mit einem Faktor von 33% ja auch bestätigst. Hoch, da man bei nicht nur bei Servern eine garantierte Verfügbarkeit ab etwa 99% fordert (~Darf an höchstens 3 Tagen im Jahr defekt sein). Hochverfügbarkeit hingegen bedeutet etwa 99,999%.--Nmoas 21:08, 28. Sep. 2009 (CEST)

Ich hatte 14TB Lesestoff kalkuliert, da 2TB ja durch den ersten Defekt wegfallen. Zudem sind 8 Ports ja ne durchaus realistische Größe für Controller.

Wie 33%? Erfolgsrate für einen Zugriff ist P==(1-10^-14). Angenommen, es sind voneinander unabhängige Ereignisse, dann multiplizieren sich deren Wahrscheinlichkeiten. Für vier Zugriffe sind das P*P*P*P = P^4 ≈ 0,999999999999960. Für 14TB = 14 * 10^12 Bytes * 8 Bit/Byte sind das A=1,12*10^14 Ereignisse, und P^A sind nunmal 0,3263. Die Chance auf einen Lesefehler beträgt also 1- diesen Wert

Ich versteh nicht wo Dein Problem ist, Du schreibst in 33 von 100 Fällen - das ist für mich das Gleiche wie ein "Gelingfaktor" von 33%.--Nmoas 20:21, 4. Okt. 2009 (CEST)

Für mich auch. Und ein Problem hab ich damit nicht, eher du. Wobei ich auch nicht weiß, woher das kommt und auf was es sich bezieht.--Mathias 15:45, 9. Okt. 2009 (CEST)

@Verfügbarkeit: Rechne mal die Zeit für eine Rekonstruktion aus Backups dagegen.

Gegen was? Gegen eine EMC2 Raid 6+2 Installation und einen Plattentausch? --Nmoas 20:21, 4. Okt. 2009 (CEST)

Hast du irgendwelche Beraterverträge mit EMC und kassierst Provision?--Mathias 15:45, 9. Okt. 2009 (CEST)

Wenn deine Backupquelle etwas über ein halbes GB/s hergibt, der diensthabende Admin nur auf den Totalcrash wartet, und dein RAID-Controller durch einen oder mehrere Quadcores ein ganzkleinwenig Rückenwind bekommt, dann bist du bei voll genutztem Array in 8 Stunden fertig. Passiert das 1x im Jahr ist die Verfügbarkeit maximal 99,91%. Hochverfügbarkeit (HA) ist nach DEINEM Edit ab etwa 99,99%.

Gehts noch? Pfusch ich in deinen Textzeilen rum?

99,91% oder 99,99%, was ist der Wesentliche Unterschied, es geht doch nur um eine Größenordnung, daher auch meine "weiche" Formulierng: "oft 99,99% oder besser". Aber einige Quellen/Hersteller sagen auch nur 99,9% oder aber 99,999% andere sogar noch mehr, im Wikiartikel Hochverfügbarkeit wird das ja daher auch wie folgt beschrieben: Die genaue Definition von Hochverfügbarkeit kann variieren ... Nur: niemand wird ein 99% verfügbares System heute noch als HOCHverfügbar bezeichnen. Was willst Du überhaupt mit diser "Backup-Theorie" aussagen? --Nmoas 20:21, 4. Okt. 2009 (CEST)

Wir reden hier vom Unterschied zwischen einer Ausfallzeit von 50 Minuten gegenüber einem drittel Tag, jährlich gesehen. Völlig irrelevant, oder was? --Mathias 15:45, 9. Okt. 2009 (CEST)

Um das zu erreichen, darf so ein Event also nur 1x pro Dekade vorkommen, ergo eigentlich gar nicht. Ist die Geschwindigkeit des Backups realistischer, hat der Admin auch sonst noch was zu tun, und darf sich der RAID-Controller alleine abmühen, dann sinds ruckzuck unter 99,5% abzüglich Rekonstruktion der Daten seit dem Backup. Das reicht aber immer noch locker für Verfügbarkeitsklasse 2--Mathias 19:28, 1. Okt. 2009 (CEST)

Ich verstehe den kompletten Absatz nicht: @Verfügbarkeit? Was willst Du damit sagen? Ich kenne keinen Nutzer der so heist.

Man kann sich auch dumm stellen. Und nach allen heutigen Edits in dieser Diskussion seh ich keinen Sinn darin, diese fortzuführen. Such dir einen EMC-Fan, mit dem du die Vorzüge von RAID60 auf 2400 Disks haarklein aufstellen kannst, aber verschone den Artikel mit unpräzisen bis falschen Formulierungen, die für Privatpersonen und Unternehmen mit einem Hardwarebudget im sub-Millionen-Bereich auch noch absolut irrelevant sind. Ich habe fertig.--Mathias 15:45, 9. Okt. 2009 (CEST)

Hat das was mit dieser Diskussion zu tun oder mit dem Artikel zu Hochverfügbarkeit? Wenn ja was? Was für 99,5%. Wie kommst Du auf einmal zur Verfügbarkeitsklasse 2? Ich verstehe den kompletten Absatz echt nicht, was ist die These? Was soll gezeigt werden?--Nmoas 20:21, 4. Okt. 2009 (CEST)

Verfügbarkeitsklasse 2 steht so auf der Seite zur Hochverfügbarkeit.--Mathias 15:45, 9. Okt. 2009 (CEST)

Meine Aussage ist dass alle professionellen Systeme hochwertige Platten nutzen sollen und nicht nur HA Systeme. Und die Warnung ist: Vorsicht bei großen Consumerfestplatten (~2TB) in RAID 5 und ähnlichen RAID Leveln. Vor allem wenn man z. B. 8 Platten im RAID 5 fahren will, kann es dann leicht zu Problemen kommen - daher nutzt man bei großen Platten besser RAID 1, 10 oder auch RAID 50. 3 große Platten machen bei RAID 5 statistisch gesehen noch kaum Probleme, 6 oder 8 (und mehr) aber schon! Daher sage ich auch: bei vielen großen Platten nutzt RAID 50 (oder 60 oder 10)! --Nmoas 20:21, 4. Okt. 2009 (CEST)

An Mathias: Wenn du mit diskutieren willst, musst du diszipliniert und sachlich bleiben. --Nmoas 07:12, 10. Okt. 2009 (CEST)

DROBO BehondRAID

Ich habe gerade eine Beschreibung des externen Speichers DROBO gelesen und frage mich, ob dessen "BeyondRAID" eine eigenständige RAID-Variante ist oder nur ein Markennahme um das Produkt besser bewerben zu können. Leider habe ich zu wenig Ahnung von RAID, um das klären zu können. Kann das einer von Euch? Ist Drobo tatsächlich was grundlegend Neues und damit ein Lemma wert? --Was ist Diskriminierung? Was möchtest du loswerden? 09:55, 6. Nov. 2009 (CET)

Nach der Webseite versteh ich NULL, Verkaufgeschwafel. :-) Nach en:BeyondRAID scheint es nur eine intelligentere Zwischenschicht, Verwaltung zu sein und mehreres Funktionen zu kombinieren. Primär ist es ein Markenname (TM). --Franz (Fg68at) 09:14, 8. Nov. 2009 (CET)

redundante "Redundanz"

"Streng genommen handelt es sich bei x nicht um ein wirkliches RAID - es gibt keine Redundanz" - Diesen Satz liest man im Artikel häufig, Satzwiederholungen sind unschön und wirken fast wie fanatisches Gerede; ich empfehle eine Entfernung der Redundanz und stattdessen eine einmalige, klar abgegrenzte Nennung des Umstandes im oberen Bereich des Artikels - die sinntragende Aussage ist eher im Bereich "nice-to-have" einzuordnen statt vielfach rezitiert werden zu müssen (nicht signierter Beitrag von 88.66.155.29 (Diskussion | Beiträge) 11:28, 16. Nov. 2009 (CET))

Begriff "Stripe Size"

Die Erklärung des Stripe Size unter Begriffe ist vermutlich falsch. Stripe size, chunk size, segment size, oftmals auch block size, stripe length oder granularity bezeichnen alle das gleiche: "den kleinsten Datenblock pro Schreibzugriff, der auf eine individuelle Festplatte geschrieben wird." -- Holgerf 09:57, 2. Dez. 2009 (CET)

Anleitung für das Wiederherstellen eines NVIDIA Raid 1-Systems nForce 520

Die nachfolgende Anleitung ist nicht nur falchs, sondern führt auch ziemlich sicher zu Datenverlust und widerspricht nebenbei den Richtlinien für Wikipedia-Diskussionsseiten. Damit das keine/r nachmacht und dann sagen kann „aber in wikipedia steht's so“ habe ich den Beitrag durchgestrichen. MfG, --R.Schuster 21:43, 25. Jun. 2010 (CEST)

NVIDIA nForce 520 Raid 1 wiederherstellen

Also ich habe es jetzt einfach durch Ausprobieren selbst herausgefunden. Ihr sollt aber auch wissen, wie es geht. Falls ihr also euer nVidia Raid 1 durch irgend einen Fehler zerstört habt und beim booten anstatt einem weiß geschriebenem Array auf einmal zwei rot blinkende Arrays mit dem Status "DEGRADED" auftauchen, haltet euch an meine Anleitung.

Voraussetzungen für die Anleitung: Windows ist auf den Platten im Raid installiert und von mindestens einer der beiden Platten bootbar (Raidtreiber sind also schon installiert).

Hier die Step-by-step Anleitung:

1. lösche die Partitionstabelle von einer der beiden Festplatten, indem du die Computerverwaltung öffnest, dann auf Datenträgerverwaltung klickst und bei dem Datenträger, auf dem C: nicht existiert, alle Partitionen mit der rechten Maustaste löschst.

2. du musst herausfinden auf welcher der beiden Platten die Daten sind. Dazu fährst du deinen PC herunter und steckst einfach eine Festplatte aus. Startet dein PC normal, machst du mit Schritt 3 weiter. Startet er nicht, ist die Festplatte angeschlossen, die jetzt ohne Partitionstabelle (also sozusagen leer) ist. Stecke sie aus und die andere wieder ein. Jetzt sollte der PC normal starten.

3. starte den PC neu und drücke sobald er komplett heruntergefahren ist mehrmals auf F10 um ins RAID-Bios zu gelangen. Dort sollte jetzt ein Raid Array mit dem Status "DEGRADED" auftauchen. Drücke ENTER, damit du mehr Informationen zu dem Array bekommst und schreibe dir die Nummer die die vorne dran steht auf (z. B. 1.1). Mit ENTER kommst du zurück zur Array-Liste. Mit Strg+x kommst du dann ganz aus dem Bios raus und den PC startet neu. Schaltet ihn entweder bevor er bootet aus oder fahre ihn nachdem er gestartet ist wieder herunter.

4. schließe jetzt die 2. leere Festplatte wieder an und schalte den PC an. Drücke wieder mehrmals auf F10. a) wird nur ein Array angezeigt (immer noch "DEGRADED" und wenn man ENTER drück mit gleicher Nummer) mache gleich mit Schritt 5 weiter. b) Werden zwei Arrays angezeigt, drücke ENTER und finde heraus, bei welchem eine andere Nummer angezeigt wird (z. B. 1.2). Lösche dieses Array durch drücken der Taste d und bestätige mit y (bzw. z, weil beim englischen Tastaturlayout ist die y-Taste an der Stelle wo beim deutschen die z-Taste ist). Jetzt wird das angezeigt, was unter 4.a) beschrieben ist und du kannst auch mit 5. weiter machen.

5. Drücke ENTER um die Detailansicht des Arrays zu bekommen. Am unteren Bildschirmrand gibt es eine Funktion Rebuild, die mit Drücken der Taste r aufgerufen wird. Jetzt wird einem eine Liste angezeigt, in der normal nur die leere Festplatte zur Auswahl steht. Diese wählt man durch drücken der Taste a (für add=hinzufügen) aus und fügt sie dem Array hinzu. Jetzt sollte auf in der Array-Liste ein Array mit Status "REBUILD" angezeigt werden. Drückt man Enter wird eine Liste mit den beiden Festplatten angezeigt. Durch erneutes ENTER-Drücken kommt man wieder zur Array-Liste. Dort kann man das RAID-Bios mit Strg+x verlassen (nicht warten bis sich der Status ändert! Noch werden die Daten nicht kopiert).

6. Der PC sollte jetzt einwandfrei starten und nach kurzer Zeit sollte im Tray-Bereich (rechts unten) eine Meldung kommen in der steht, dass das Array wiederhergestellt wird. Das dauert dann je nach Geschwindigkeit und Größe der Festplatten bis zu mehreren Stunden (z. B. braucht eine 100GB-Platte die 30MB/s schreiben kann fast eine Stunde). Während dieser Zeit kann der PC genutzt werden. Ich rate aber davon ab. Ich weiß nicht wie gut die Treiber wirklich sind und ich denke, dass es das beste ist, wenn ihr ihn einfach in Ruhe lasst. Brecht aber auch nicht in Panik aus, wenn euer Virenscanner plötzlich mit dem Update anfängt. Normal sollte der Rebuild trotzdem erfolgreich beendet werden.

7. Ist alles fertig, könnt ihr den PC benutzen oder wer auf Nummer sicher gehen will kann einen Neustart machen und schauen, ob der Status des Array (wird ja beim Start des PCs angezeigt) wieder auf "HEALTHY" steht.

8. (ganz wichtig) SICH FREUEN, dass man das System nicht neu aufsetzen muss ;)

Ich hoffe, dass hilft allen, die eine ähnliches Problem wie ich hatten.

Gruß Xaver (nicht signierter Beitrag von 84.137.206.78 (Diskussion) 07:55, 30. Jan. 2009 (CET))

- 2010 -

RAID 6 mit "diagonalem XOR" oder "RS-Code"

Was ist (in Hardware-/Software-RAID) üblicher? Was sind von diesem und jenem die Vor- und Nachteile? --RokerHRO 13:25, 16. Feb. 2010 (CET)

RAID 1E0 falsch!

s. http://publib.boulder.ibm.com/infocenter/eserver/v1r2/topic/diricinfo/fqy0_craidx0.html Gruss LAZA 09:29, 17. Mär. 2010 (CET)

Ergänzung: RAID-Probleme?

Bereits mehrfach ist mir untergekommen, dass ein RAID Level 1 Datenverlust erlitt. Ursache: eine von zwei Festplatten fiel nicht aus, sondern erlitt partiellen Datenverlust. Die HDD meldete keinen Fehler und der RAID-Controller spiegelte deshalb die defekten Daten auf die zweite, noch funktionierende HDD (wobei er die korrekte Kopie ersetzte). Dadurch hat die Einführung des RAID die Ausfallwahrscheinlichkeit nicht halbiert, sondern verdoppelt. Das RAID insgesamt erlitt Datenverlust bereits dann, wenn 1 Festplatte fehlerhaft arbeitete. Kann jemand dieses Verhalten aus eigener Erfahrung bestätigen, oder kann Ursachen im Sinne einer fehlerhaften Konfiguration, näher ausführen? Ich vermute als Ursache, dass die Festplatte ein Billigmodell ohne eigene Fehlererkennung war. Sollte dies jemand bestätigen können, wäre es sinnvoll einen entsprechenden Hinweis in den Artikel aufzunehmen.--91.35.143.183 10:37, 24. Mär. 2010 (CET)

Dieses Verhalten kann nur auftreten, wenn der RAID-Controller DEFEKT ist.

Kurze Frage: Was ist das für ein RAID-Controller? Welches Betriebssystem?

Der RAID-Controller ist dafür verantwortlich, die Konistenz der beiden Kopien zu gewährleisten.

Der RAID-Controller ersetzt nicht eine Kopie durch die andere, sondern arbeitet wie folgt:

Schreibender Zugriff - Beide Kopien werden parallel geschrieben.

Beim fehlerhaften schreibenden Zugriff, wird der Block als fehlerhaft markiert, und auf einen anderen freien Block umgelenkt. Voraussetzung ist, das genügende freie Disk-Blocks zur Verfügung stehen. In jedem Fall wird aber eine Fehlermeldung an das System verschickt.

Lesender Zugriff - Controller liest von der Platte, die den korrekten Block am Schnellsten liefern kann.

Beim fehlerhaften lesenden Zugriff, wird der Block als fehlerhaft markiert, und auf Grund der Redundanz-Bedingung der zweite Block gelesen. Erst wenn der nächste Schreibvorgang stattfindet, wird der als fehlerhaft markierte Block vom Lesevorgang auf einen freien Block umgelenkt.

"Die HDD meldete keinen Fehler und der RAID-Controller spiegelte deshalb die defekten Daten auf die zweite, noch funktionierende HDD (wobei er die korrekte Kopie ersetzte)."

Ein RAID-Controller spiegelte nicht die Kopien von der einen auf die andere Platte. Solche Verfahren gibt es nur beim Software-RAID. Diese Software-RAIDs sichern sich aber durch die so genannte "Mirror Write Consistency" ab, die auf jeder Disk im RAID definiert ist. In diesem Bereich sind alle fehlerhaften Blocks gelistet. Dadurch wird genau dieses verhindert, das eine fehlerhafte Kopie eine korrekte Kopie ersetzt.

Gruß WoKi (nicht signierter Beitrag von 84.169.43.214 (Diskussion | Beiträge) 23:43, 15. Apr. 2010 (CEST))

Ausfallwahrscheinlichkeit RAID 0

Kann man das bitte auch in deutsch zusammenfassen? Auch, wenn es nicht so exakt wie 1 − (1 − p)n ist? ^^

-- Sukram71 19:40, 25. Apr. 2010 (CEST)

Was genau verstehst du an der Formel bzw. an dem Absatz, in dem sie erklärt und hergeleitet wird, nicht? --RokerHRO 19:59, 25. Apr. 2010 (CEST)

alles :) Man könnte ja auch schreiben: Mit 2 Platten verdoppelt sich die Ausfallwahrscheinlichkeit. Mit weiteren Platten entsprechend. Halt mit allgemeinverständlichen Worten. Zumal es eh relativ sinnlos ist, eine Ausfallwahrscheinlichkeit bis auf die letzte Kommastelle auszurechnen, wenn es sowieso vom Zufall abhängt, ob der Fall der Fälle eintritt. ^^ ---Sukram71 22:52, 25. Apr. 2010 (CEST)

RAID6 = weniger gebräuchlich/bedeutungslos?

Was soll denn diese schwachsinnige Einsortierung? Weder ist RAID6 bedeutungslos noch ungebräuchtlich. Das Gegenteil ist vielmehr der Fall: Jedes halbwegs ernsthafte Rechenzentrum nutzt 6 statt 5... --Cálestyo 23:48, 5. Mai 2010 (CEST)

Hallo. Hast Du einen Beleg für diese Aussage? Die Rechenzentren die ich kenne nutzen nämlich alle RAID 10. --R.Schuster 22:07, 25. Jun. 2010 (CEST)

S.M.A.R.T und RAID-Systeme?

Das Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.), zu deutsch System zur Selbstüberwachung, Analyse und Statusmeldung, ermöglicht das permanente Überwachen wichtiger Parameter und somit das frühzeitige Erkennen drohender Defekte.

Doch ist die Information auch bei RAID-Systemen abfragbar? (nicht signierter Beitrag von 79.237.179.65 (Diskussion) 08:57, 22. Jun. 2010 (CEST))

Das eine hat mit dem anderen nichts zu tun. S.M.A.R.T. ist eine Sache der Platten - unabhängig ob auf der platte Daten sind oder nicht. RAID sorgt dafür, dass die Daten "schlau" auf den Platten verteilt werden. Natürlich gibt es RAID-Controller die die S.M.A.R.T.-Daten überwachen und beim Überschreiten von Grenzwerten den Rebuild-Prozess auf eine Hot-Spare-Platte starten - aber dennoch hat es nichts mit dem RAID-Array ansich zu tun. --suit Datei:Rebell at 13x13.jpg 13:35, 28. Jun. 2010 (CEST)

Anzahl der Platten bei Raid1

Der Absatz Raid1 suggeriert, das ein Raid1 aus mehr als zwei Platten bestehen kann. In der Praxis scheint dies jedoch nicht der Fall zu sein!? Was hindert die Hersteller/Programmierer daran alle verfügbaren Platten, trotz Platzverschwendung, aber mit dem Ziel hoher Leseperformance zu Spiegeln/Kopieren? -- Apofis 09:17, 15. Jul. 2010 (CEST)

Weil es bessere Möglichkeiten gibt um einen Performancegewinn zu erzielen - z.B. Load-Balancer, Replikation von Datenbanken, RAM-Disks - im Enterprise-Segement ist die Performance selbst wenig ausschlaggeben, da die Platten heutzutage ohnehin schon sehr schnell sind und wenn mehr gebraucht wird gibt es eben zuverlässigere, bessere Technologien oder einfach Wirtschaflichere Technologien. Was nutzt es, wenn die Platten ein Fileservers eine durchschnittliche Lesegeschwindigkeit von mehreren Hunder MB/s haben, die Netzwerkverbindung aber auf 1 GBib/s beschränkt ist? --suit Datei:Rebell at 13x13.jpg 09:32, 15. Jul. 2010 (CEST)

Mir ging es speziell im Bereich DMS um viele Millionen kleine Dateien. Von einem Raid1 über viele Platten hätte ich mir eine bessere Zugriffzeit erhofft. -- 80.152.133.23 10:43, 15. Jul. 2010 (CEST)

Die Zeiten liegen im Millisekundenbereich, das dürfte wohlkaum relevant sein --suit Datei:Rebell at 13x13.jpg 11:52, 15. Jul. 2010 (CEST)

Es gibt nicht viele RAID-Controller/Adapter die mehr als zwei Platten pro RAID1 unterstützen. Hatten uns damals extra einen Firmware-Patch bauen lassen, damit der RAID-Adapter mehr als zwei Platten beim RAID1 unterstützt. Alternativ kann man ein LVM-Mirroring durchführen. Die meisten LVMs unterstützen bis 3 Platten für die Spiegelung. Heutzutage verwendet man für solch ein Zugriffsverhalten SSDs (READ-Zugriffszeit 4K = 280 µs).

"Die Zeiten liegen im Millisekundenbereich, das dürfte wohlkaum relevant sein"

IRRTUM: Bei RealTime-Applikationen machen manchmal Differenzen von 1 ms den Unterschied zwischen performant und in-performant aus (Mussten wir damals schmerzlich erfahren).

Hatte mal 2xRAID1 mit 5 Platten je 15 Mill. Dateien pro RAID1 (READ-Zugriffszeit 4K = 3,2ms). In diesem Umfeld (RealTime) war die READ-Zugriffszeit bis max. 4ms gefordert und das entscheidende Mass der Dinge. SSDs (Solid State Drive) waren zur Aufbau-Zeit 2004 noch viel zu teuer. Die Verarbeitung musste innerhalb einer Processor-Timeslice von 10ms durchgeführt werden. Die Berechnungs-Engine benötigte allein ca. 4,5 - 5,5ms der Timeslice.

Hier mal ein Beispiel für ein RAID1 mit mehr als 2 Platten - FC Disk (15K RPM):

Zylinderanzahl=90774

READ: Seek(min)=0,2ms , Seek(avg)=4,7ms , Seek(max)=9,5ms

WRITE: Seek(min)=0,5ms , Seek(avg)=5,3ms , Seek(max)=10,3ms

S(x) = Seek Time, R = Rotationslatenz und AT = Access Time = Zugriffszeit

A) RAID1 mit 2 Platten

READ S(x)=3,8ms ; R= T/3=4/3ms -> AT=5,13ms -> IOPS = 195

WRITE S(x)=6,7ms ; R=2T/3=8/3ms -> AT=9,37ms -> IOPS = 107

B) RAID1 mit 3 Platten

READ S(x)=3,2ms ; R= T/4=1ms -> AT=4,2ms -> IOPS = 238

WRITE S(x)=7,3ms ; R=3T/4=3ms -> AT=10,3ms -> IOPS = 97

C) RAID1 mit 5 Platten

READ S(x)=2,5ms  ; R= T/6=2/3ms -> AT=3,16 ms -> IOPS = 316

WRITE S(x)=7,93ms ; R=5T/6=3,33ms -> AT=11,26ms -> IOPS = 88

Aber wie schon gesagt, heute würde man dafür SSDs verwenden. SSDs sind dafür wesentlich sinnvoller, als x-Platten zu einem RAID1 zusammenbauen.

Gruß WoKi (nicht signierter Beitrag von 84.169.5.85 (Diskussion) 00:57, 20. Jul 2010 (CEST))

Werte in den Tabellen Zusammenfassung, RAID

RAID 10 und 0+1 "Übersicht über die Kombinations-RAIDs" Zusammenfassung nicht richtig:

Nettokapazität für RAID 10 bzw. analog RAID 1+0 ist nicht immer n/2:

i ... Anzahl der Festplatten in einem Leg
j ... Anzahl der Legs
n ... Anzahl der Festplatten ( i * j = n)
Voraussetzung: i >= 2, j >=2
=> Für RAID 10 und i > 2 gilt diese Aussage nicht
=> Für RAID 0+1 und j > 2 gilt diese Aussage nicht

richtig müsste sein (ohne Quelle/n):

=> RAID 10: j (da (i - 1) Festplatten pro Leg wegfallen => Nutzbarer Speicher: n - (i - 1) * j = j) 
=> RAID 0+1: i (da alle Legs gespiegelt sind entspricht der gesamte Speicher der Anzahl von Platten in einem Leg)

-- Csae2414 15:07, 19. Aug. 2010 (CEST)

RAID DP

Im Abschnitt "5.7 RAID DP" wird die Berechnung der beiden Paritäten beschrieben - das kann so aber nicht stimmen.

Beispiel:
Wenn Festplatten A und C ausfallen, dann kann A2 und C2 rekonstruiert werden, aber nicht A1, A3, C1 und C3.
A1 kann nicht aus P1 rekonstruiert werden, da C1 nicht verfügbar ist.
A1 ist nicht in einer diagonalen Parität enthalten.
A3 kann nicht aus P3 rekonstruiert werden, da C3 nicht verfügbar ist.
A3 kann nicht aus Q2 rekonstruiert werden, da C1 nicht verfügbar ist.
C1 kann nicht aus P1 rekonstruiert werden, da A1 nicht verfügbar ist.
C1 kann nicht aus Q2 rekonstruiert werden, da A3 nicht verfügbar ist.
C3 kann nicht aus P3 rekonstruiert werden, da A3 nicht verfügbar ist.
C3 ist nicht in einer diagonalen Parität enthalten.

Gemäß der Beschreibung des Einzelnachweises [7] (http://www.usenix.org/publications/library/proceedings/fast04/tech/corbett/corbett.pdf) habe ich es mit 4 Festplatten und allen Ausfallkombinationen durchgespielt - damit ist alles rekonstruierbar.

Leider weiß ich nicht, ob man nur die diagonale Parität Q für 3+2 Festplatten anders berechnen muss oder ob man mindestens 4+2 Festplatten braucht. (nicht signierter Beitrag von 93.132.169.248 (Diskussion) 16:27, 24. Okt. 2010 (CEST))

Ist Raid-DP wirklich eine Weiterentwicklung von Raid4? Meiner Meinung nach, und auch laut Netapp, ist es eine Weiterentwicklung von Raid6.-- 93.244.206.72 12:21, 20. Nov. 2010 (CET)

Natürlich RAID 4 denn RAID 5 und RAID 6 stammen ja selbst auch von RAID 4 ab. Auch scheint es dedizierte Parity Platten zu geben beides gibt es bei RAID 5 und 6 nicht. Oder man köbnnte auch sagen, es fehlen die Stripes, daher also kein RAID 5 oder 6 sondern RAID 4! Marketing-Leute mögen es nicht gerne, wenn etwas von unmodernen, kaum noch gebräuchlichen "Uralt-Systemen" abstammt, daher sucht man wohl die Verwandtschaft zu RAID 6, was in sofern ähnlich ist, als es ja auch 2 tote Platten verschmerzen kann.--Nmoas 04:32, 23. Nov. 2010 (CET)

RAID 01

Folgendes scheint mir falsch zu sein (Siehe RAID#Performance Absatz "IOPS und MB/s bei RAID 5" , ist auch nicht belegt):

Im ungünstigen Fall muss bei RAID 01 (Anm. nmoas) mit erheblichen Leistungseinbußen und erhöhter Ausfallwahrscheinlichkeit gerechnet werden, da die Schreib-/Leseköpfe beim sequentiellen Schreiben permanent hin- und herspringen müssen.

Das müssen Köpfe ja eigentlich immer, es kommt auf die Effizienz an. Die Effizienz der Kopfbewegungen entsprechen dem Verhältnis max. nutzbaren netto IOPS zu brutto möglichen IOPS also bei RAID 5 mit 3 Platten zwischen 25% bei kleinen Blöcken und 66% bei kompletten Stripesets (Siehe RAID#Performance Absatz "IOPS und MB/s bei RAID 5"); bei RAID 01 immer 50% - was also effizienter beim schreiben ist - also die Mechanik besser schont - lässt sich pauschal nicht sagen.--Nmoas 04:51, 26. Okt. 2010 (CEST)

Bei RAID 01 mit drei Festplatten hängt es davon ab, wie es realisiert wurde. Wenn es so gestaltet ist wie in der Skizze, dann würde das bedeuten, dass die Schreib-/Leseköpfe mit jeder Schreibakti--Björn König 15:05, 1. Nov. 2010 (CET)on wild über die Platte springen, wenn Anfang und Mitte der Festplatte physisch weit auseinander liegen. Meinetwegen muss das aber nicht gesagt werden, weil RAID-01 mit drei Festplatten sowieso ziemlich exotisch und daher in der Praxis kaum interessant ist. --Björn König 15:42, 29. Okt. 2010 (CEST)

Dadurch wird die Mechanik der Festplatten deutlich stärker belastet als bei RAID 5. Sofern es die sonstigen Umstände zulassen, sollte daher RAID 5 bevorzugt werden.

Was nicht aufgezeigt wurde - Im Gegenteil: umfassen die Schreibzugriffe relativ kleine Blockgrößen (< Stripesize), dann geht die Kopf-Mechanik von Platten im RAID 5 etwa doppelt so schnell kaputt als bei RAID 10 Platten. --Nmoas 04:51, 26. Okt. 2010 (CEST)

Der Artikel geht von RAID 01 mit vier Festplatten aus und bringt bei der Klärung dieser Frage daher nicht weiter. --Björn König 15:46, 29. Okt. 2010 (CEST)

Doch, er hilft - denn es ändert sich bei Raid 01 mit 3, 4 oder mehr Platten praktisch gar nichts (außer eben die Anzahl Laufwerke auf die sich die Schreib-Zugriffe verteilen - die Effizienz ändert sich hierbei nicht und liegt unter Last konstant bei 50%, also einen Block schreiben resultiert immer in 2 Blöcke schreiben bzw. 2 mal Positionieren). Besonders aber Raid 5 kann bei ungünstigen Blockgrößen eine echte Tortur für die Platten sein (Effizienz nur 25% bzw. 4 mal Positionieren - siehe Artikel), das geht deutlich aus dem Artikel hervor. Über Raid 5 wird meines Erachtens viel mystifiziert, da liefert der Artikel erfrischend viel Klarheit und zeigt, dass die Eigenschaften und das Leistungsverhalten von Raid 5 von der Implementierung und vom Anwendungsfall abhängig ist - und einen günstigen und einen ungünstigen Fall kennt, für Raid 01 gilt das eben nicht, immer 50% ! --Nmoas 06:29, 1. Nov. 2010 (CET)

Nein. Er hilft nicht, denn bei RAID 01 mit drei Festplatten ändert sich praktisch eine Menge, was in dem Artikel überhaupt nicht betrachtet wird. Nämlich - wie bereits gesagt - dass die Schreib-/Leseköpfe dort deutlich mehr bewegt werden müssen. Das bedeutet mehr Belastung und darum auch höhere Ausfallwahrscheinlichkeit. Es wird ebenfalls nicht darauf eingegangen, dass ein vernünftiger RAID-5-Controller die Blöcke im Cache behält, so dass insbesondere beim sequentiellen Schreiben nicht mit jedem zu schreibenden Block zwei gelesen und zwei geschrieben werden müssen, sondern nur zwei geschrieben werden müssen. Das entlastet die Festplattenmechanik deutlich. Das es in der Praxis anders ist als dort geschrieben steht, wird nur angedeutet: "(It’s a little more complicated than that, but this is a pretty good estimate.)" Dieser Artikel geht überhaupt kein Stück auf Zuverlässigkeit ein, sondern nur auf die Frage, was schneller ist. Aus der Anzahl der Schreib-/Lesezugriffe die Zuverlässigkeit abzuleiten, halte ich für sehr fragwürdig, da eben so etwas höchst Entscheidendes wie Ausmaß der Kopfbewegungen völlig ausgeblendet wird. Dabei sind die Kopfbewegung bei RAID 01 mit drei Festplatten der bedeutendste Unterschied zu RAID 01 mit vier Festplatten und RAID 5 mit drei Festplatten. --Björn König 15:05, 1. Nov. 2010 (CET)

DOCH! Auch vom mehrfachen Behaupten wird nichts besser! Du behauptest, dass bei Raid 01 mehr Kopfbewegungen stattfinden würden als bei Raid 5, es wird aber nicht aufgezeigt oder belegt! Auch wird behauptet das bei Raid 01 mit 3 Platten mehr Kopfbewegungen nötig seien als mit 4 Platten, aber ebenfalls wird nichts aufgezeigt oder belegt! Bitte erkläre doch mal warum beim Schreiben von Blöcken (oder von Stripes) bei 3 Platten etwas anders passieren soll als bei 4 Platten im Raid 01 - spiele es doch mal durch - es wird dir nicht möglich sein - kein Artikel braucht daher auch den besonderen (und exotischeren) Fall mit 3 Platten extra zu beschreiben, auch nicht mit mehr Platten als 4 - da bleibt sich alles gleich, jedoch verteilt sich die Last auf die Anzahl Platten: Ein Block schreiben entspricht im ungünstigen (=günstigen) Fall 2 mal Positionieren, und 3 Blöcke schreiben ist 6 mal Positionieren im ungünstigen Fall (im günstigen Fall - wenn der erste Block und das Spiegelbild des 2. Blocks auf dem gleichen Zylinder/Spur liegen usw. - jedoch auch nur 3 mal positionieren bei drei Platten). --Nmoas 19:34, 3. Nov. 2010 (CET)

Was soll ich denn machen um es aufzuzeigen? Einen wissenschaftlichen Testaufbau und von unabhängigen Laboren bestätigte Testergebnisse? Wie wäre es denn mal zur Abwechselung die Vorstellungskraft einzuschalten und versuchen zu verstehen, was ich schreibe? Also zum letzten Mal, nun ganz deutlich: In der Skizze gibt es zwei Bereiche. Einen für RAID 0 und einen für RAID 1. Diese liegen gemäß der logischen Geometrie weit auseinander und können physikalisch ebenso weit auseinander liegen. Zum Beispiel wenn wenn man eine Festplatte verwendet, bei der eine ungerade Anzahl von Plattern verwendet wird. Bei einer geraden Anzahl ist es wahrscheinlich, dass logisch weit auseinander liegende Bereiche physisch sich an der selben Stelle auf den Plattern befinden, nur eben auf verschiedenen Plattern oder Platterseiten. Liegen die Anfänge der Bereiche von RAID 0 und RAID 1 nun weit auseinander, dann springt der Schreib-/Lesekopf sehr eben viel hin und her. Nämlich pro Schreibvorgang einmal über die Hälfte der Oberfläche und beim sequentiellen Schreiben anschließend wieder zurück. Das ist eine enorme Belastung. Da der Artikel hier keine Unterscheidung zwischen RAID 01 mit drei Platten und RAID 01 mit vier Platten macht, kann man getrost davon ausgehen, dass der Artikel diesen Umstand nicht berücksicht. Denn Rest Ihres Diskussionsbetrags ausführlich zu kommentieren spare ich mir aus Zeitgründen mal, denn ich merke, dass wir gründlich aneinandervorbei Palavern. Ihren Ausführungen zum Cache-Verhalten brauche ich auch gar nicht widersprechen, weil sie nicht falsch sind. Sie hätten sich nicht die Mühe machen müssen so gründlich zu antworten, wenn Sie meinen Beitrag gelesen hätten, wo ich mich ausdrücklich und ausschließlich auf sequentielle Schreibvorgänge beziehe. Alles andere ist nicht Gegenstand der Diskussion. Schönes Leben noch. --Björn König 13:02, 8. Nov. 2010 (CET)

Also, jetzt bemerke ich erstmals was da genau skizziert ist und verstehe absolut nicht warum dieses ziemlich unpraktische Layout gewählt wurde (es geht natürlich auch immer noch komplizierter - das müsste man aber auch mit einem ähnlich unsinnigen Raid 5 Layout vergleichen. ... Typ: Hauptsache der Kopf hüpft), aber einfacher ist doch sicher folgendes Layout für Raid 01 bzw. Stripes (wie Raid 0 - da werden z. B. drei Platten abwechselnd beschrieben - 1.Datenblock: Platte 1 Block 1; 2.Datenblock: Platte 2 Block 1; 3.Datenblock: Platte 3 Block 1; 4.Datenblock: Platte 1 Block 2; usw. - nicht SPAN/JBOD like wie in der Skizze!) kombiniert mit Mirroring (wie Raid 1), dann ist auch egal ob eine Platte gradzahlig oder ungradzahlig viele Blöcke hat:

Folgende Vorgehensweise ist viel einfacher: Zunächst werden die Platten (genau wie bei Raid 0) nur in fortlaufend nummerierte Chunks (hier = Blöcke) eingeteilt (beginnend mit 1) - dann werden alle Chunks mit ungeraden Nummern mit dem nächst höheren Nachbarn mit gerader Nummer gespiegelt. Der 1. Datenblock liegt dann auf Platte 1 und ist dort Block 1, sein Spiegelbild (Mirror) ist auf der 2. Platte der 1. Block. Der 2. Datenblock ist auf Platte 3 Block 1 dessen Mirror ist wieder auf Platte 1 der Block 2. Der 3. Datenblock (3.DB) ist auf 2. Platte 2. Block (2P2B), zugöriger Mirror ist 3P2B. 4.DB: 1P3B und 2P3B. 5.DB: 3P3B und 1P4B. 6.DB 2P4B und 3P4B und so weiter und so fort. Dieses Layout hat im Gegensatz zur Skizze und zur Zeichnung keine höhere Kopfbewegungsanzahl als jede andere Raid 1 oder Raid 01 Kombination. Ob ein Layout wie skizziert überhaupt irgendwo implementiert ist, wage ich zu bezweifeln, es ist einfach unnütz verkompliziert. (Man sollte daher die Skizze ändern) --Nmoas 15:23, 8. Nov. 2010 (CET)

Die Frage ist Raid 01 oder Raid 5, da spielt Cache erst mal keine Rolle, Raid 5 fordert keinen Cache. Dennoch, wenn du jetzt noch mit Cache-Hits rechnen willst, ist das die optimistische Annahme eines günstigen Falls, dass da Raid 5 gut abschneidet ist ja gar nicht fraglich. Man kann aber Raid 5 nicht mit Cache-Hit gleichsetzen, weil 1. nicht alle Systeme/Controller Cache haben, 2. Cache häufig sehr klein ist (im Vergleich zum Plattenplatz bzw. Datendurchsatz) und daher der Cache nur für sehr kurze Zeit Blocks speichert und wiederum daher bei normalerweise gut ausgelasteten Systemen und dem Raid 5 Schreiben ein Cache-Miss die Regel ist (= weit häufiger). Auch werden bei ausgelasteten Systemen die Köpfe nicht nach dem Lesen warten bis das Schreib-Kommando endlich kommt (das ist ja zu diesem Zeitpunkt noch nicht mal in einer Command-Queue - und Warten würde ja die Systemleistung herabsetzen), sondern für andere Tasks die Command-Queue abarbeiten und weitere Blöcke ansteuern. Also: Im ungünstigen Fall - bei Cache-Miss und bei kleinen Blöcken - müssen erst 2 Blöcke gelesen werden, dann erfolgt die Parity-Berechnung und dann das Schreiben. 1 Block schreiben bedeutet 4 mal positionieren - der Typ von Adaptec kennt sich aus! (Ähnliches schreibt auch Sun in einem Raid/ZFS Paper, das mittlerweile scheinbar vom Orakel gefressen wurde ...) --Nmoas 19:34, 3. Nov. 2010 (CET)

Der Artikel setzt zurecht (auch wenn es in der Realität mit unter komplizierter ist) Zugriffe mit dem Positionieren von Köpfen gleich, das ist a pretty good estimate solange man gleiche Platten hat und das sowohl bei Raid 01 als auch bei Raid 5 tut - das sollte keine Frage sein. --Nmoas 19:34, 3. Nov. 2010 (CET)

Es geht im Absatz darum den ungünstigen Fall von Raid 5 mit Raid 01 (auch Raid 1) zu vergleichen und herauszuarbeiten dass Raid 5 unter Umständern nachteilhaft sein kann und Anwender enttäuscht/getäuscht werden. Die positiven Eigenschaften von Raid 5 werden in Marketing-Blättchen immer zur Genüge herausgearbeitet, aber das ist nur die halbe (Werbe-) Wahrheit. Merke: unter allen Umständen, auch unter Vollast arbeitet ein Raid 01 (auch Raid 1) immer mit einer Effizienz von 50% (oder wenn fortlaufende Blocks geschrieben werden auch noch besser), Raid 5 hingegen kommt bei 3 Platten unter ungünstigen Bedingungen nur auf 25% (1 Block schreiben = 4 mal Kopf bewegen) (Besser nur unter günstigen Bedingungen, wie dem Schreiben von großen zusammenhängenden Blöcken, dann immerhin auf 66% also: 2 Blöcke schreiben = 3 mal Kopf bewegen - und wenn fortlaufende Stripes geschrieben werden natürlich auch noch besser, eben wie bei Raid 01 auch)! --Nmoas 19:34, 3. Nov. 2010 (CET)

Der schreibende Random-Vorgang (Block Size < Stripe Unit Size) beim RAID01 mit drei Platten muss genau wie beim RAID5 mit drei Platten auf zwei Platten je eine Kopf-Postitionierung durchführen. Beim sequentiellen Schreibvorgang - Full-Stripe-Write (Block Size >> Stripe Unit Size) müssen 3 Kopf-Postitionierungen beim RAID5 aber 4 Kopf-Postitionierungen beim RAID01 auf drei Platten durchgeführt werden, um den kompletten Stripe-Satz (A1, A2, A3) zu schreiben. Damit ergibt sich ein Positionierungsverhältnis 3/3 beim RAID5 gegen 4/3 beim RAID01. Die IOPS (I/O Operationen pro Sekunde) enthalten alle zeitlichen Elemente (Positionierungs-, Rotationslatenz-, Transfer- und Queuing-Zeiten), die für den Vorgang vom Start bis zur Beendigung der I/O-Anforderung benötig wurde. Mit der Anzahl an Kopf-Postitionierungen hat die Größe IOPS nur über die zeitliche Kompomente damit zu tun.

Beispiel: Zeitliche Elemente beim einzelnen Disk-Zugriff im Read-Modify-Write Mechanismus für RAID5

(S(r) + R ) +	2R/D +	(2R - 2R/D) +	2R/D
[Lese-Positionierung + Rotationslatenz]	[Daten lesen]	[Rotationslatenz - Daten lesen]	[Daten schreiben]
		(Übergang: Lesen->Schreiben)

D = Data units per track = (Sectors/Track * SectorSize) / BlockSize

Damit erhält man für die Zugriffszeit beim Read-Modify-Write Mechanismus: t(RMW) = S(r) + (3 + 2/D) * R

Die Gesamt-Zugriffs-Zeit beim Read-Modify-Write Mechanismus im RAID5 beträgt also rein statistisch 2*t(RMW). Des weiteren sind die Inter- und Intra-I/O-Parallelitäten für die Größen IOPS oder MB/s wesentlich bestimmend.

Anmerkung: Die Daten/Werte im Beitrag "Performance" sind ziemlich trivial ermittelt und stimmen nur bedingt.

-- WoKi (nicht signierter Beitrag von 84.169.17.136 (Diskussion) 22:38, 24. Nov. 2010 (CET))

Noch mal der Hinweis: es geht um das worst case Schreib-Verhalten von RAID 5 - Well case Annahmen wie Full-Stripe-Write, große Blöcke, sequentielles Schreiben usw. haben dem worst case Schreib-Verhalten von RAID 5 nichts zu tun, und gehen am Thema "worst case Schreib-Verhalten" vorbei! Ein guter Einstieg bietet: picking-the-right-stripe-size@adaptec. Danach bitte nicht mehr die SektorSizes und die Stripe- oder Chunk-Sizes bunt durcheinander würfeln.--Nmoas 03:43, 26. Nov. 2010 (CET)

Die Annahme dass bei RAID 5 und kleinen Blöcken (siehe oben) der Kopf nach dem Einlesen der Sektoren wartet (denn erst nach dem Einlesen können die Paritys berechnet werden) bis dann der resultierende Schreibbefehl in der command-queue der Platte landet - ist nur dann richtig, wenn ein System quasi idle ist - es ist eine well case Annahme! Auch kann man nicht pauschal davon ausgehen, dass die zu lesenden Sektoren in einem Cache vorgehalten werden, z. B. bei CoW-Dateisystemen (und Cache auf Controllern) ist das die Ausnahme und nicht alle Systeme haben überhaupt Cache oder genug Cache - in well case und unter vielen alltäglichen Bedingungen reist es der Cache - ja das ist nicht die Frage - aber nicht unter worst case Bedingungen. (Das zeigen aber auch Benchmarks: RAID 5 bleibt zum Teil hinter den Erwartungen zurück: [8] oder [9]) Steht ein System unter (hoher) Last, dann enthalten die command-queues der Platten weitere Befehle und der Kopf ist längst bewegt worden - und wartet nicht! MFM- oder RLL- oder PATA-Platten haben früher vielleicht (???) gewartet (die konnten ja auch noch kein command-queueing) aber bereits aktuelle SATA-Laufwerke und Controller nutzen das command-queueing und überlassen das optimale Kopfpositionieren der Platte (denn die kennt ja auch die tatsächlichen positionen der Cylinder, Heads oder auch redirechted Blocks usw.) - mal ganz abgesehen von SCSI oder SAS. Also es bleibt dabei, im worst case bedeutet RAID 5: commands in der read-queue plazieren - 2 mal Kopfpositionieren zum Einlesen - Rückliefern - Parity berechnen - command in der write-queue plazieren - und zwei mal Kopfpositionieren zum Schreiben. (Es kann eine Kopfbewegung eingespart werden, aber nur dann wenn der neue Block sofort nach dem Einlesen geschrieben wird und in kauf genommen wird, dass das Parity kurz falsch bleibt - bedeutet aber ein erhöhtes Risiko!) Bei Raid 01 hingegen sind es immer 2 Kopfbewegungen zum schreiben! --Nmoas 03:43, 26. Nov. 2010 (CET)

Hinweis: In der Praxis hat das schlechtere Worst-Case-Verhalten von RAID 5 nur selten merklich negative Einflüsse (Beispiele: [10] oder[11]), was unter anderem daran liegt, dass vergleichsweise kleine Blöckgrößen von 512 Byte selten vorkommen. Weiter nutzen aktuelle Systeme Cache-Strategien, um dieses Verhalten zu eliminieren. Dennoch sind Anwendungsfälle denkbar, bei denen die verminderte Worst-Case-Effizienz zutage tritt! (Z.B. ein Server der bevorzugt SMS-Nachrichten in einzelnen Dateien ablegt.) In diesem Fall sollte RAID 10 oder RAID 01 bevorzugt werden, obgleich in den meisten Fällen RAID 5 die performantere Lösung sein wird und dazu noch mehr nutzbaren Plattenplatz bietet.--Nmoas 03:43, 26. Nov. 2010 (CET)

Man unterscheidet kein Worst-Case und Well-Case Verhalten, sondern zufällige (Random) und sequentielle Zugriffe/Aufträge. Zu den Definitionen, die Sector Size beschreibt die Größe vom Daten-Sektor der Festplatte und die Block Size ist die Zugriffsgröße vom System/Auftrag. Die Stripe Unit Size beschreibt die Größe pro Platte und die Stripe Size die komplette Größe vom Stripe-Set. In vielen Papern wird die Stripe Unit Size gleich der Stripe Size gesetzt, was der ursprünglichen Definition laut Patterson, Katz und Chen widerspricht.

Der wesentliche Unterschied zwischen Plattenauftrags- und Prozessorzeitscheduling ist die Nicht-Unterbrechbarkeit von Plattenaufträgen. Sind sie einmal an die Platte abgeschickt, so werden sie fertig abgearbeitet und erst danach können andere Aufträge bearbeitet werden. Ein logischer Schreibauftrag, der vom System abgeschickt wird, sieht das RAID wie eine Einzel-Platte.

Wenn ein logischer Schreibauftrag an das RAID5 abgeschickt wird, dann müssen alle notwendigen physischen Vorgänge stattfinden, um den entsprechenden Schreibauftrag zu erfüllen. Da wird keine "Pause" eingelegt um einen anderen Auftrag zu bedienen. In der Command Queue wird nur dieser eine logische Schreibauftrag eingereiht, da wird nichts in lesende und schreibenden Kommandos unterteilt. Das ist ein schreibender Auftrag mit zwei intern-gruppierten lesenden und schreibenden Anweisungen. Nicht für umsonst nennt sich dieser logische Random-Schreib-Auftrag auch Read-Modify-Write Mechanismus.

Es bleibt dabei, zwei Kopfbewegungen beim Random-schreibenden Auftrag auf RAID5!

Ohne Tagged/Native Command Queuing schickt der Treiber einen neuen Auftrag erst an die Platte, nachdem der vorherige abgeschlossen wurde. Diese Vorgehensweise hat aber den Nachteil, dass die Platte in der Übertragungszeit des Auftrags und in der Abschlusszeit des vorhergehenden nicht ausgelastet ist. Command Queuing ermöglicht es nun bereits vor Abschluss eines Auftrags weitere an die Platte zu schicken. Die Platte hat sogar die Möglichkeit, die Abarbeitungsreihenfolge der schon an sie geschickten Aufträge zu verändern, das heißt sie kann selbst die Aufträge planen.

-- WoKi (nicht signierter Beitrag von 84.169.16.168 (Diskussion) 04:29, 27. Nov. 2010 (CET))

• Tom Treadway (If the writes are short and random ... the IO rate is cut to ¼) und ich, wir zählen unter ungünstigen Voraussetzungen 4 Kopfbewegungen (also eine Effizienz von 25% oder 1/4 )! --Nmoas 11:18, 27. Nov. 2010 (CET)

• Ich unterscheide well case und worst case Verhalten und lasse mir das auch nicht verbieten! Da sich 84.169.16.168 ja besser auszukennen scheint als Tom Treadway erspare ich mir jeden weiteren Kommentar - wer aber auch nicht glaubt was 84.169.16.168 schreibt kann sich hier schlau machen: http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/ --Nmoas 11:18, 27. Nov. 2010 (CET)

Ich bezweifele sehr stark das man sich unter http://storageadvisors.adaptec.com/2006/06/05/picking-the-right-stripe-size/ "schlau" machen kann. Aber entscheiden Sie selbst, welche Darstellung/Beschreibung Ihnen zum Verständnis vom Read-Modify-Write Mechanismus beim RAID5 besser zusagt.

----------------------------------------------------------------------------------------------

Vielleicht kann nachfolgende Beschreibung zu einem besseren Verständnis führen.

Es gibt im RAID5-Mode folgende Read/Write-Operationen:

1. Read - Normal Mode

2. Read - Degraded Mode

3. Write - Read-Modify-Write (wenn Update Size < 1/2 Stripe Size)

4. Write - Reconstruct/Partial Stripe (wenn Update Size > 1/2 Stripe Size)

5. Write - Full Stripe (wenn Update Size = Stripe Size)

6. Write - Degraded Mode

Nachfolgenden ist die schematische Anweisungs-Sequenz vom Read-Modify-Write einmal dargestellt. Dabei sind Spezial-Behandlungen in Verbindung mit ZLA (Zero-Latency Access), RPS (Rotational Position Sensing), Disk-Arm Scheduling, Error Correction Code (ECC) und Caching-Mechanismen von mir aus Übersichtlichkeit weggelassen. Manche Routinen sind auch Patent-rechtlich geschützt und dürfen sowieso nicht veröffentlich werden. Im Allgemeinen sieht die Anweisungs-Sequenz in der RAID Firmware/Microcode beim Read-Modify-Write Mechanismus wie folgt aus (Das Ampersand & steht für parallele Ausführbarkeit):

activate async disks -- Aktivierung asynchroner Disk-Zugriff (Entkoppelung - Seek und Rotation)

BEGIN RMW

get_parity (

Rotation Delay LBA-Parity -- Verzögerungs-Wert bis Start-LBA Parity

Seek LBA-Parity -- Kopf-Positionierung LBA-Parity über Zylinder

Settle 15 LBA-Parity -- Kopf-Feinpositionierung über LBA-Parity innerhalb eines Zylinders

Read LBA-Parity from disk -- Lesen Parity

Skew 0 LBA-Parity -- Kein Versatz durchführen

) &

get_data (

Rotation Delay LBA-Data -- Verzögerungs-Wert bis Start-LBA Data

Seek LBA-Data -- Kopf-Positionierung LBA-Data über Zylinder

Settle 15 LBA-Data -- Kopf-Feinpositionierung über LBA-Data innerhalb eines Zylinders

Read LBA-Data from disk -- Lesen Data

Skew 0 LBA-Data -- Kein Versatz durchführen

) &

stop bit get_parity & -- Warte auf Werte Parity

stop bit get_data & -- Warte auf Werte Data

Thread -> Calc CKSUM/Parity & -- Berechnung Parity

Thread -> Rotation Delay LBA-Parity & -- Verzögerungs-Wert bis Ziel-LBA Parity

Thread -> Rotation Delay LBA-Data & -- Verzögerungs-Wert bis Ziel-LBA Data

Return Thread -> Calc CKSUM/Parity -- Rückgabe Neu-Wert Parity

stop bit calc -- Warte bis Rückgabe Neu-Wert Parity

Return Thread -> Rotation Delay LBA-Parity -- Ziel-LBA der Parity erreicht

Settle 3 LBA-Parity & -- Kopf-Feinpositionierung über LBA-Parity

Write LBA-Parity to disk -- Schreiben vom Neu-Wert der Parity

stop bit write parity -- Warte bis Neu-Wert Parity geschrieben ist

Return Thread -> Rotation Delay LBA-Data -- Ziel-LBA der Data erreicht

Settle 3 LBA-Data & -- Kopf-Feinpositionierung über LBA-Data

Write LBA-Data to disk -- Schreiben vom Neu-Wert der Data

stop bit write data -- Warte bis Neu-Wert Data geschrieben ist

Release skew -- Versatz-Freigabe

END RMW

activate sync disks -- Aktivierung vom synchronen Disk-Zugriff (Synchronisation - Seek und Rotation)

Standardmäßig arbeitet jedes Hardware-RAID im synchronen Ausführungs-Algorithmus. Beim Read-Modify-Write Mechanismus wird aber der asynchroner Ausführungs-Algorithmus (Start Bits und Stop Bits notwendig) gewählt, damit wird eine relativ hohe Inter-I/O-Parallelität (MEHRERE Aufträge verteilen sich gleichzeitig auf MEHRERE Platten) ermöglicht, die mit dem synchronen Ausführungs-Algorithmus nicht möglich wäre. Die Reihenfolge vom Write-Anweisungs-Block für DATA und PARITY können auch dynamisch ermittelt und durchgeführt werden.

Die SKEW-Anweisung ist eine SuperSet-Anweisung, steht also über der Seek-Anweisung. Es gibt drei verschiedene SKEW-Anweisungen Head-Skew (h_skew), Cylinder-Skew (c_skew) und Head/Cylinder-Skew (skew). Diese Skew-Anweisungen sind für Read-Ahead und sequentielle Read/Write Disk-Zugriff nötig und kosten weniger Zeit als Seek-Anweisungen. Die SKEW-Anweisung "skew 0 LBA" verhindert, dass der aktive Head (Kopf) und der momentane Zylinder gewechselt werden darf. Die SKEW-Anweisung lässt aber bestimmte Set/SubSet-Anweisungen z.B. SETTLE (Kopf-Feinpositionierung), DPR (Dynamic Path Reconnect), DPS (Dynamic Path Selection) und einige andere zu. Die Kopf-Feinpositionierung (SETTLE) wird innerhalb eines Zylinders durchgeführt. Der Read/Write-Kopf muss beim Lesen/Schreiben über der Spur gehalten werden. Der SETTLE-Wert gibt dabei an, wie groß der Toleranz-Bereich der Kopf-Auslenkung über der Spur sein darf. Die SETTLE-Zeit liegt bei ca. max 0,5 ms und hat daher einen relativ geringen Einfluss auf die Zugriffszeit. Zumal die Feinpositionierung parallel zur Rotation, aber nicht parallel zur Seek stattfinden kann.

Ich hoffe, dass diese Darstellung etwas Klarheit in den Read-Modify-Write Mechanismus bringt.

-- WoKi (nicht signierter Beitrag von 84.169.2.179 (Diskussion) 00:33, 30. Nov. 2010 (CET))

• Und wenn es noch zehn mal behauptet wird und sich hier jeder besser auskennt als Adaptec oder http://www.yellow-bricks.com/2009/12/23/iops/ oder http://www.soug.ch/fileadmin/user_upload/Newsletter/NL_public/Oracle_Performance.pdf (usw. usf.), und jetzt feingranuliert dargeboten wird - All das ändert nichts an der FALSCHEN Grundannahme des unabdinglichen Wartens!. Dass nach dem Einlesen der alten Werte gewartet wird (also der Kopf unabdinglich auf der Spur stehen bleibt), bis die neuen Paritywerte berechnet sind, ist eine Annahme die zumindest nicht allgemein gültig ist. Ich bleibe dabei, dass das zwar möglich ist (z. B. wenn ein System keine/wenig Load hat) aber dass das under heavy load auch immer so klappt: Nein. Denn dazu müsste vor einem "kleinen" Schreibzugriff das Command-Queueing ausgeschaltet sein/werden (was es aber nicht unbedingt so ist), oder die Platte müsste bereits beim einlesen wissen dass gleich ein Schreibzugriff folgt (also Read-Modify-Write Mechanismus kennen, davon weiss die aber nichts), oder es könnte gewartet werden bis die Readqueues leer/abgearbeitet sind (Ideal für Server ;-))) gähn ). - Also: Dass das unbedingt immer so implementiert wird, ist schlicht falsch. - Server mit vollen (read) I/O queues warten nicht! Das gewartet wird ist zwar möglich, aber eben eine well case Annahme! --Nmoas 13:03, 1. Dez. 2010 (CET)

• Zur zitierten SKEW Methode, die ist im United States Patent 7334081 von Hitachi hinterlegt, eingereicht im April 2005 und erteilt im Februar 2008. Natürlich können das nicht alle Festplatten und daraus folgt natürlich: diese Methode darf nicht allgemein genutzt werden und ist somit nicht überall und immer implementiert. --Nmoas 07:45, 2. Dez. 2010 (CET)

• Auch Sun/Oracle kennt das Problem, daher kann man bei SUN/Oracle unter den ZFS Docs nachlesen, warum RAID 5 (oder 6) und das Caching im FileSystem-Prozess des OS implementiert werden sollten (dortiges Pendant zu Raid-5 ist RAID-Z1) und wie CoW Filesysteme, bei integriertem RAID und Cache, dann das RAID 5 write Penalty (read-read-write-write) bei "kleinen" Schreibzugriff sicher umgehen können (wenn es das Penalty nicht gäbe - wozu das Ganze?). (FYI: Bei CoW weiss der FS-Prozess schon lange im Voraus wo die nächsten Änderungen hingeschrieben werden. Der Prozess kennt somit Position und Größe schon lange, sogar schon vor dem Entstehen des Schreibbefehls - ein externer Controller hingegen nicht - und hat dann natürlich lange vorab alle betroffenen Blocks im Cache - Ein in-place FS hingegen kennt den zu ändernden Block nie nicht im Voraus - und in Folge den zu schreibenden Block auch nicht - daher die 4 I/Os wenn alles dumm läuft) --Nmoas 07:45, 2. Dez. 2010 (CET)

Ich habe nichts gehen diese 4 I/Os. Mit diesen 4 I/Os ist aber die Transfer-Anzahl von und zu den Disk-Devices gemeint und nicht die Anzahl an Kopf-Postionierungen. Am besten einfach mal eine SCSI Block Command Set Dokumentation für die XOR-Operation Devices anschauen. Da werdem Sie schnell erkennen, dass nicht 4 Kommandos an die Disk-Devices gesendet werden, sondern nur 2 Kommandos [XDREADWRITE und XPWRITE] oder [XDWRITE EXTENDED und XPWRITE] (ähnlich arbeitet SATA und IDE). Das XDREADWRITE/XPWRITE Kommando enthält eine Read- und eine Write-Transfer-Anweisung auf das Disk-Device. Zur Wiederholung: Das ist ein schreibender Auftrag mit zwei intern-gruppierten lesenden und schreibenden Anweisungen. Innerhalb des SCSI Kommandos wird die Spur/Track nicht gewechselt, dass kann über ein SEEK (EXTENDED SEEK) oder SKEW oder RELADR Steuer-Kommando erreicht werden. Solange keine CHECK CONDITION oder RELEASE oder RESET Anweisung abgesetzt wird, bleibt der Kopf über der momentanen Spur/Track. Die Kommando-Queue vom RAID-Device ist für die Aufträge, die vom Host/Server kommen, warum soll man das beim RMW abschalten? Das RAID5 arbeitet beim RMW-Mechanismus im ASYNCHRONEN MODUS, also Transaktions-orientiert über START BITS und STOP BITS. Deshalb können die beiden X*WRITE Kommandos quasi parallel an die beiden Disk-Devices gesendet werden, nur wegen der Data-XOR-Berechnung (CHECK CONDITION XOR-DATA) muss die Write-Anweisung innerhalb des XPWRITE Kommandos warten (Write Hole). Die Erkennung vom RMW, Partial Stripe und Full Stripe ist ganz einfach: Request Size / Stripe Unit Size = m. Drei Write-Fälle: m <= (n-1)/2 - RMW; m > (n-1)/2 - Partial Stripe; m >= (n-1) Full Stripe wobei n die Disk-Anzahl ist.

Das RAID-Z1 von SUN hat keinen Read-Modify-Write Mechanismus, sondern nur Full Stripe Writes. Da beim RAID-Z1 die Datenverfügbarkeit (Sicherheit) im Vordergrund stand, ist das Schreiben nicht besonders effizient. Auch deswegen nicht effizient, weil ein Software-OS-RAID zwar die Seek der Devices synchronisieren kann, aber die Rotation kann es nicht synchronisieren. Das Transaktions-orientierte Logging (Journaling) und die B+ Bäume der Daten/Metadaten (bzw. Meta-Metadaten) haben andere FileSysteme (in AIX, HP/UX und einigen anderen UNIX-Systemen) schon seit über einen Jahrzehnt. Beim Lesen sind diese Software-RAIDs meistens besser als Hardware-RAIDs, beim Schreiben meist schlechter.

-- WoKi (nicht signierter Beitrag von 84.169.13.16 (Diskussion) 23:50, 7. Dez. 2010 (CET)) 9

Nun mit SCSI Beispiel... Die SCSI XOR Commands wurden um das Jahr 2000 von IBM und von Seagate etwas früher eingeführt, und zwar erst mal nur bei Fibre Channel, beide Hersteller schreiben, dass nicht alle Laufwerke die Befehle implementieren. Man kann also keineswegs sicher sein, dass die Befehle von jeder FC- oder SCSI-Platte implementiert werden - schon gar nicht bei ATA! Dort wurde Tagged Command Queuing (wie bei SCSI - auch die XOR Commands werden hierunter als Erweiterung geführt) 2002 und auch nur von IBM eingeführt, mangels Unterstützung von der Controller-Seite aber kaum genutzt. Die alternative Implementierung Native Command Queuing von Seagate für SATA-Laufwerke wurde 2003 vorgestellt. Ob es heute eine einheitliche Norm gibt die TCQ und NCQ umfasst konnte ich nicht herausfinden. Beide ATA-Erweiterungen sind, wie auch die SCSI XOR Commands, optional... Soviel zum allgemeinen Stand der Technik.--Nmoas 13:32, 10. Dez. 2010 (CET)

Nochmal, es geht nicht darum was mit besonderen Vorkehrungen möglich ist oder idealer Weise sein könnte! Sondern darum was im ungünstigen Fall vorliegt. Die angeführte SCSI Befehlssequenz sagt hierüber nichts aus. Ich kann dazu nur betonen, dass das RAID 5 write Penalty noch 2008 (bzw. 2005) Gegenstand von Forschungen war (Hitachi) und deshalb sicher nicht jede Methode, die Abhilfe verspricht, in existierenden Systemen implementiert ist. Dazu bräuchte man erstens das Datum des Erscheinen solcher Befehle im SCSI-, SATA und IDE- Befehlsatz (alle drei!) und zweitens das Einführungsdatum der zugehörigen Norm die besagt, dass diese Befehle auch zwingend immer implementiert sein müssen. Erst dann sind RAID- Implementierungen die davon Gebrauch machen auch zeitlich einzuordnen. --Nmoas 12:12, 9. Dez. 2010 (CET)

Aus dem Satz : "Da beim RAID-Z1 die Datenverfügbarkeit (Sicherheit) im Vordergrund stand, ist das Schreiben nicht besonders effizient." lese ich, dass (zumindest nach Ansicht von 84.169.13.16) bei RAID 5 das effiziente Schreiben (wohl die RMW-Optimierungen) im Vordergrund stehen und die Sicherheit nur als zweitrangig angesehen wird. - Glaube ich zwar nicht, aber diese Ansicht ist doch Interessant - Redundanz zweitrangig?!?!. Meiner Ansicht nach steht in den meisten Einsatzfällen von RAID nach wie vor die Sicherheit (Redundanz) im Vordergrund. - Das bedeutet dann aber auch: RAID 5 ist unsicherer als RAID 1 oder RAID-Z1 (oder RAID-10 usw.) und das bedeutet (wenn es wahr wäre) tschüss RAID 5. Und tatsächlich die oben beschriebene Methode/Befehlssequenz lässt das Raid System ja wirklich für einige Zeit inkonsistent. Das impliziert die Formulierung: "X*WRITE Kommandos (arbeiten) quasi parallel"; meint aber, dass das zweite Write-Kommando wartet, bis das erste Write-Kommando seine geänderten Daten abliefert und in dieser vermeidbar langen Zeit passen Daten und Parity nicht zusammen. Solch ein Vorgehen kann man sich höchstens bei Kontrollern mit Batterie-Pack vorstellen oder wünschen. Es bleibt zu hoffen, dass angesehene Hersteler auf solchen Leichtsinn verzichten.--Nmoas 12:12, 9. Dez. 2010 (CET)

Auch ist die Einschätzung von ZFS und RAID-Z1 falsch, es ist wegen der Implementierung der Caches innerhalb des FS-Treibers anderen CoW Dateisystemen (die sich ausschließlich auf die externen Caches der RAID 5 Controller verlassen müssen) überlegen, sowohl beim Schreiben als auch beim Lesen. Das RAID 5 write Penalty können CoW Dateisysteme besonders einfach deswegen eliminieren, weil sie erstens alle Writes gruppieren können und somit nach belieben komplette Stripes schreiben, und zweitens sie kennen den Ort (den Stripe, den Chunk und auch den Sektor) an dem zukünftig geschrieben wird bereits lange im Voraus und können auch diese Bereiche (wenn grad sonst nichts zu tun ist) vorab einlesen und im Cache halten. Somit können auch kleine Blöcke ohne das sonst notwendige unmittelbar vorherige Lesen (also ohne Penalty) und ohne Warten des Kopfes über einer Spur, sofort geschrieben werden. - Damit auch RAID-Controller oder SAN Systeme mit integriertem RAID 5 (oder ähnlich) optimal mit CoW Dateisystemen und RAID 5 zusammenarbeiten, müsste es eine Art CacheWrite-Ahead-Befehl geben, der dem Controller sagt, dass er die angegebenen Sektoren (z. B. gleich einen gesamten Stripe - oder auch mehrere Stripes) schon mal auf Vorrat für zukünftige Schreiboperationen in den Cache lesen soll und auch dort lässt, bis sie zum Schreiben genutzt werden. Solange es das nicht gibt könnte alternativ der CoW-FS-Treiber zum besseren Cache-Fill, besonders dann, wenn grad sonst nichts zu tun ist, diese Sektoren auch in kurzen Zeitabständen immer wieder anfordern. --Nmoas 12:12, 9. Dez. 2010 (CET)

Link defekt?

Der Anker-Link zu Raid 5 in nachfolgender Zeile scheint defekt zu sein!?

"Wegen der fest definierten Paritätsplatte bei RAID 4 wird stattdessen fast immer RAID 5 bevorzugt."

--Pedak 11:23, 25. Nov. 2010 (CET)

Danke für den Hinweis. Habs repariert. Gruß —[ˈjøːˌmaˑ] 11:39, 25. Nov. 2010 (CET)

- 2011 -

Bilder von Festplatten

Was spricht gegen die Bilder bzw. die anderen Kleinigkeiten? Siehe http://de.wikipedia.org/w/index.php?title=RAID&diff=83895681&oldid=83567204 -- Pemu 12:17, 25. Jan. 2011 (CET)

Musikwiedergabe = große Datenmengen in kurzer Zeit?

Aus dem RAID 0 Abschnitt:

Der Einsatzzweck dieses Verbundsystems erstreckt sich demnach auf Anwendungen, bei denen in kurzer Zeit besonders große Datenmengen vor allem gelesen werden sollen, z. B. auf die Musik- oder Videowiedergabe und die sporadische Aufnahme derselben.

Das trifft auf Video- und Musikschnitt zu, bei Videos je nach Format eventuell auch auf Aufnahme und Wiedergabe, bei Musikwiedergabe und -Aufnahme (in Echtzeit) aber sicher nicht, da selbst bei unkomprimierten Audioformaten die Datenrate um Größenordnungen unter dem was eine Festplatte ohne RAID schafft sind (z.B. blu-ray max. 27,658 Mb/s = 3,456 MB/s laut en:Blu-ray#Audio, moderne HDDs schaffen sogar im Innenbereich min. das 10-20-fache im sequentiellen Zugriff), außer vielleicht bei wenigen professionellen Anwendungen, wo sehr viele Channels gleichzeitig aufgezeichnet werden, aber für diese ist RAID 0 ohnehin zu unzuverlässig. --101010 21:20, 24. Feb. 2011 (CET)

Fehler in den pro des Softwareraids

Zitat: Dieser Vorteil kommt besonders beim Disaster Recovery zum tragen, wenn der RAID-Controller defekt und nicht mehr verfügbar ist – praktisch alle derzeit verfügbaren Software-RAID-Systeme benutzen die Festplatten so, dass diese auch ohne die spezielle Software ausgelesen werden können. Bei dieser Variante kann der Festplatten-Cache aktiviert bleiben.

Das funktioniert doch nicht generell? Bei Raid5 z.B. hab ich doch immer nur ein Bruchteil einer Datei oder die Parität auf der Platte. Som,it ist doch da nix mit auslesen? Denn was mach ich mit nem kleinen Futzel oder nem Paritätsteil einer Datei?

An dieser Stelle ist meines Erachtens der Artikel sehr missverständlich... (nicht signierter Beitrag von 93.208.123.23 (Diskussion | Beiträge) 23:21, 14. Jan. 2011 (CET))

Ich denke es ist gemeint, dass die unterschiedlichen Raid Implementationen untereinander kompatibel sind, so das man den Raidcontroller durch einen beliebigen anderen ersetzen kann. Aber das sollte nochmal jemand der sich besser auskennt bestätigen. --Grumml 10:09, 9. Mai 2011 (CEST)

Controller-Cache mit Pufferbatterie

Mich dünkt der Abschnitt zum Controller mit Cache und Pufferbatterie etwas sehr negativ. Gute Controller verfügen über Batterien, welche relativ lange halten. Im Falle eines Mainboard-Defekts kann man zB. die Platten samt Controller auf ein anderes System migrieren und die Schreiboperationen beenden. Je nach Betriebssystem werden bei Adaptern ohne Pufferbatterie die Schreiboperationen nicht gecacht (sondern nur Leseoperationen), was die Performance sehr stark drücken kann. Das alles muss nicht gegen eine Absicherung des Raumes mit einer USV sprechen, eher als Ergänzung. --Jackobli 22:44, 23. Mär. 2011 (CET)

Ungerade Anzahl von Festplatten bei RAID 5

Im RAID 5-Abschnitt des Artikels wurde geschrieben, dass es vorteilhaft ist, wenn ein RAID 5-System mit einer ungeraden Anzahl von Festplatten aufgebaut ist. Ich kann das Beispiel mit 2048 Byte zu schreibenen Daten nachvollziehen, aber es könnten ja genauso gut 1536 Byte zu schreiben sein. Dann würde es bei drei Nutzfestplatten und einer Paritätsfestplatte auch hinkommen (3 * 512 Bytes). Oder ist es so, dass die Blockgrößen der Dateisysteme immer ein Vielfaches von 1 Kilobyte sind?--Section6 06:14, 4. Mai 2011 (CEST)

"Ein Datenblock ist die kleinste in einem Zugriff les- oder schreibbare Einheit (heute meist 512 Byte groß, da diese Größe der Clustergröße des Ur-Unix-Dateisystems entspricht; zukünftig 4096 Bytes, da das die Mindestclustergröße moderner Betriebssysteme ist, also eine kleinere Datenblockgröße immer acht mal soviele Schreibvorgänge bedeuten würde)." Vielleicht hilft das, Zitat von Datenblock. Gruß --Grumml 10:22, 4. Mai 2011 (CEST)

Hardware RAID

Im Artikel steht im Abschnitt "Hardware RAID" unter anderem: "Er kann im Gehäuse des Computers enthalten sein. Besonders im Rechenzentrums-Umfeld befindet er sich häufiger in einem eigenen Gehäuse, einem Disk Array, in dem auch die Festplatten untergebracht sind. Die externen Systeme werden oft auch als DAS oder SAN bezeichnet, seltener auch NAS, wenngleich nicht jedes dieser Systeme auch RAID implementiert."

DAS, SAN und NAS sind keine Synonyme die nach Seltenheit genutzt werden :D DAS ist ein eigenständiges System, das Festplatten an einen Computer direkt anbinden kann. (Als würde man eine Festplatte an einen PC anstecken) SAN ist ein eigenständiges System, das Festplatten an einen Computer direkt anbinden kann, wobei der Datentransfer über das Netzwerk läuft aber das Dateisystem vom zugreifenden Rechner verwaltet wird. (Als würde man eine Festplatte anstecken, und PC und Platte liegen weit voneinander entfernt) NAS ist ein eigenständiges System, das Festplatten an einen Computer anbinden kann, wobei der Datentransfer über das Netzwerk läuft und das Dateisystem vom NAS verwaltet wird. (Als würde man auf einem PC Dateien "freigeben" und mit einem anderen PC darauf zugreifen) (nicht signierter Beitrag von 90.146.106.233 (Diskussion) 13:55, 8. Jul 2011 (CEST))

Festplatten-Cache?!

In dem Artikel wird über die Aktivierung oder Deaktivierung vom Festplattencache gesprochen, was scheinbar auf den RAID-Betrieb Auswirkungen hat. Nirgendwo vorher wird aber das Zusammenspiel mit RAID und die Konsequenzen des Benutzens des Caches in diesem Zusammenhang erläutert, so daß der Leser sich entweder aus anderen Quellen Informationen holen muss oder sich versuchen muss vorzustellen warum nun in einem Fall der Cache "folglich" aktiviert bleiben kann und warum im anderen Fall nicht. Es fehlt also eine Erklärung im Vorfeld. -- 92.73.188.52 13:56, 17. Jul. 2011 (CEST)

EDIT (weiteres): Im Unterabschnitt Statistische Fehlerrate bei großen Festplatten wird ein Beispiel genannt, der allein aus dem zuvor Gelesenen kaum nachvollziehbar ist. Im übrigen ist da eine neue Vokabel Rebuild eingeführt, die in diesem Zusammenhang auch nicht wirklich erklärt wird, was das Verständnis leider nicht erhöht. -- 92.73.188.52 14:25, 17. Jul. 2011 (CEST)

RAID 0 (Striping)

Leider steht im Beitrag, dass RAID 0 und JBOD gleich zu setzen sind. Das kann nicht sein weil, beim JBOD ist die Geometrie nicht definiert ist. Im Gegensatz ist bei Striping die Festplatte - wie der Name schon vermuten lässt - in Datenstreifen untergliedert. Somit ist der Verweis auf JBOD irreführend. -- Arnisz 23:19, 29. Aug. 2011 (CEST)

Hallo Arnisz. Im Artikel steht nicht, dass RAID 0 und JBOD gleichzusetzen sind, sondern dass unter JBOD weitere Informationen zu diesem Begriff zu finden sind. Ich habe den Abschnitt jetzt mit „Array of Independent Disks“ verlinkt, dann gibt es keine Missverständnisse. MfG, --R.Schuster 09:30, 12. Sep. 2011 (CEST)

Widerspruch & zyklischer Verweis

Unter der Ueberschrift "RAID 03" heisst es lediglich:

 RAID 03 ist gleichwertig mit RAID 30.

Folgt man dem Link zum entsprechenden Abschnitt, wird "RAID 30" beschrieben als

 ein RAID 0, welches mehrere RAID 03 zusammenfasst

Das steht zum Einen im Widerspruch mit dem vorherigen Zitat, und zum Anderen ist es nicht besonders hilfreich, fuer die Erklaerung was "RAID 03" denn jetzt ist wieder zu Selbigem zurueck verlinkt zu werden... :-/
--85.180.75.3 08:45, 25. Nov. 2011 (CET)

RAID 6: Grafik

Im Abschnitt RAID 6 steht Folgendes:

Im einfachsten Fall wird eine zusätzliche XOR-Operation über eine orthogonale Datenzeile berechnet, siehe Grafik.

Wo ist denn bitte diese Grafik? Was soll ich mir unter dieser orthogonale (= rechtswinklig gedrehten) Datenzeile vorstellen? -- 87.164.172.141 21:23, 6. Dez. 2011 (CET)

Beispiel unverständlich/mangelhaft

Dieser Transtec-Controler verwendet den Begriff "Rebuild" auch. Rebuild heisst zu Deutsch "Wiederaufbau". Die redundante Platte wird wiederaufgebaut.

Im Abschnitt Statistische Fehlerrate bei großen Festplatten steht der folgende hübsche Satz:

Besteht ein Array also beispielsweise aus acht je 2 TB großen Platten, so garantiert der Hersteller nur noch, dass der Rebuild – statistisch gesehen – mindestens in einem von drei Fällen ohne URE klappen muss, obwohl alle Laufwerke korrekt nach Herstellerspezifikation funktionieren.

Also mich verwirrt dieses Beispiel eher als das es irgendetwas besser verständlich macht, was von Beispielen ja erwartet wird. Mir ist der direkte rechnerische Zusammenhang zum davor Gesagten nicht klar geworden, zumal da ein hübscher Anglizismus verwendet wird, der weder in der deutschen Wikipedia enthalten ist noch in der englischen Wikipedia in irgendeiner Form enthalten ist, das entfernt etwas mit IT zu tun hat, namentlich REBUILD. Ich glaube ich habe das Wort gehört aber ich glaube in Zusammenhang mit Programmierung oder ähnlichem, aber in Speichertechnologien kann ich mir da nicht viel darunter vorstellen. Wenn dieser Anglizismus ein etablierter ist wundert es mich doch, dass bis dato noch kein Artikel dazu existiert, weswegen ich schon mal vorsorglich einen toten Link zum noch zu erstellenden Artikel einbaue. Der Schreiber sollte in seinem Rede(Schreib-)fluss vielleicht vorher mal überlegen was er wie formuliert und ob gegebenenfalls Links zu (hoffentlich) vorhandenen Artikeln vonnöten sind. Liegt es jetzt daran, dass ich zu doof bin um das Beispiel zu verstehen oder ist das Beispiel nicht gut durchdacht oder erklärt? -- 77.177.162.0 22:41, 11. Dez. 2011 (CET)

Antwort siehe Bild. --hg6996 10:23, 21. Jan. 2012 (CET)

2. Antwort: Rebuild ist DER übliche Fachterminus für den RAID-Wiederaufbau. Vgl auch engl "to rebuild a house" = "ein Haus wieder aufbauen" (dict.cc). Der Begriff kommt in unserem Artikel ja anschließend - korrekterweise - noch etwa 10x vor. Schick wäre natürlich, ihn vor der ersten Verwendung zu erklären, das stimmt! Ich weiß nur im Moment nicht wo, oberhalb passt es m.E. nirgends ins Thema. -- 81.173.137.120 16:49, 1. Mär. 2012 (CET)

Ich habe einfach mal "rebuild" in den zweiten Absatz der Einführung eingebaut. Ich denke, dass der kurze Nebensatz das ganze nicht zu sehr aufbläht, und als grundlegende Funktion von RAIDs ist die prominente Position eigentlich gerechtfertigt. --92.231.123.26 01:22, 7. Aug. 2012 (CEST)

- 2012 -

Software RAID

Meines Wissens ist ein Software RAID immer an das Betriebssystem gekoppelt, mit dem es erstellt wurde. Das sollte in pro/contra erwähnt werden. Das heißt: Ich kann die Festplatten in einen anderen Rechner mit gleichem Betriebssystem transplantieren, aber ich könnte nicht mit verschiedenen Betriebssystemen auf dem gleichen Rechner (z.B. Dual-Boot, Linux und Windows) auf das gleiche Software RAID zugreifen. Ich bin mir nicht sicher, ob und unter welchen Umständen es möglich wäre, beispielsweise mehrere Linux-Installationen auf einem Rechner zu haben, die auf das gleiche Array zugreifen. Ich kann's aber nicht mit Sicherheit sagen, deshalb nur der Eintrag hier. Wenn genug Leute zustimmen, wäre es schön, wenn jemand das in den Artikel schreiben könnte. --92.231.123.26 01:22, 7. Aug. 2012 (CEST)

Raid 10 - falsche Grafik

die Grafik zeigt, wenn auch etwas verschlungen ein Raid 01 (jede Stripplatte ist gespiegelt)... nur weil man die Platten anders sortiert, wird daraus noch kein Raid 10!--Albing 13:51, 20. Jan. 2012 (CET)

Die Grafik ist m.E. richtig. Bei R10 handelt es sich um ein RAID0 über mehrere Spiegel (s.Text, der auch korrekt ist). Und genau das zeigt die kritisierte Abbildung. Deutlicher wäre sicher eine Abbildung über 3 Spiegel - aber korrekt ist es auch so. -- 81.173.137.120 16:44, 1. Mär. 2012 (CET)

- 2013 -

Raid 51 fehlerhaft

Bei einem Raid 51 dürfen auch bei sechs Festplatten bereits vier davon ausfallen falls nicht mehr als eine des gespiegelten Raid 5 betroffen ist. Bei einem Raid 5 darf eine Platte ausfallen also ist das Raid 5 weiterhin unbeschädigt und kann erneut gespiegelt werden. Ebenso ist bereits bei einem sechs Festplatten Raid 51 der Ausfall dreier platten ohne Datenverlust (ein Raid 5 wäre zwar defekt, aber das gespiegelte ist noch vollständig). (nicht signierter Beitrag von 178.27.162.60 (Diskussion) 02:56, 29. Mär. 2013 (CET))

Inexpensive/Independent

RAID ist ein Akronym für engl. „Redundant Array of Independent Disks“, also „Redundante Anordnung unabhängiger Festplatten“ (ursprünglich engl. „Redundant Array of Inexpensive Disks“; deutsch „Redundante Anordnung kostengünstiger Festplatten“; was aus Marketinggründen aufgegeben wurde).

Und wer hat bestimmt, dass das I nicht mehr für "Inexpensive", sondern für "Independent" steht? --MrBurns (Diskussion) 22:43, 29. Mär. 2013 (CET)

Concatenation

Concatenation kann man nicht nur verwenden, um mehrere Festplatten als eine erscheinen zu lassen, sondern auch umgekehrt (eine Festplatte erscheint als mehrere). Das ist z-.B. ein sinnvoller Trick, wenn man eine HDD mit >2,2TB unter Windows XP x32 in voller Größe nutzen will. --MrBurns (Diskussion) 05:19, 7. Mai 2013 (CEST)

3D-RAID ergänzen?

Nur mal als Idee ob man 3D-RAID ergänzen sollte. Von Google entwickelt und patentiert: http://www.google.com/patents/US8316260 (nicht signierter Beitrag von 217.89.51.202 (Diskussion) 09:18, 15. Mai 2013 (CEST))

Ein Patetent allein reicht wohl noch nicht, wegen den Relevanzkriterien. --MrBurns (Diskussion) 00:19, 16. Mai 2013 (CEST)

Wie viele Platten bei RAID6 ratsam?

Hallo,

ich habe dem Artikel entnommen, dass es bei RAID 5 aus Performancegründen sinnvoll ist, 3, 5 oder 9 Platten zu haben.
Gehe ich dann recht in der Annahme, dass es bei Raid 6 (eine Platte mehr Paritätsdaten) dann sinnig wäre 4, 6 oder 10 Platten einzusetzen?
Wobei 4 Platten RAID6 auch wenig Sinn macht: Dann kann man auch je 2 Platten Spiegeln (RAID1) und hat eine höhere Verfügbarkeit, weil beim Ausfall und Austausch keine Neuberechnung nötig ist. (nicht signierter Beitrag von Robinkoh98 (Diskussion | Beiträge) 19:39, 24. Jun. 2013 (CEST))

Gruß
--Robin (Diskussion) 17:59, 24. Jun. 2013 (CEST)

Ich denke, prinzipiell wäre jede Plattenzahl ab 4 möglich und sinnvoll, nur ist bei 4 platten 2 x RAID1 oder RAID01/RAID10 sinnvoller, daher praktisch gesehen macht RAID6 ab 5 Platten Sinn bzw. wegen dem Performanceunterschied, falls es wirklich so ist, dass man für eine gute Performance jeweils eine Platte mehr einzusetzen erst ab 6 Platten. --MrBurns (Diskussion) 22:49, 24. Jun. 2013 (CEST)

Software RAID Pro -- Kosten

Vielleicht sollte man als Pro-Punkt noch erwähnen das Software RAIDs es erlauben an der Hardware zu sparen.

Beispiel ist ein Festplattenbay mit 24 Festplatten und 4 TB

Das macht aktuell (gleiche Festplatten, gleicher Hersteller des Gehäuses u.s.w.) einen Preisunterschied von knapp 2000 € aus ob man ein Bay mit oder ohne RAID-Controller nimmt.

Bei einem Software RAID brauche ich nicht extra ein Gehäuse mit RAID-Controller den ich abschalten muss und somit unnötig mit bezahlen, denke dass das doch ein nennenswerter Vorteil ist.

46.115.59.51 12:59, 5. Jul. 2013 (CEST)

Dopplung und Syntaxproblem

Bitte unter 9.1. "Andere Begriffe / Cache" mal prüfen, das holpert. Der Absatz mit der Namenserklärung von RAID ist vom Beginn des Artikels kopiert. Der letzte Absatz dieses Unterpunktes holpert vollkommen: "damit beim Ausfall einzelner Komponenten das RAID als Ganzes seine Integrität und Funktionalität behält und nach Ersetzen der au Der Lese-Cache ist heute in Datenbank-Anwendungen oft von großer Bedeutung, da hierdurch fast nur noch zum Schreiben auf das langsame Speichermedium zugegriffen werden muss." Hier ist wohl beim Kopieren etwas schiefgelaufen. 217.5.243.52 14:05, 25. Sep. 2013 (CEST)

Zuverlässigkeit von RAID5 bzw. RAID50

Soweit ich weiß, haben mitlerweile alle großen Anbieter die Unterstützung für RAID5 und verwandte Arten eingestellt bzw. raten ausdrücklich von dessen Einsatz ab.

Hintergrund ist die mit zunehmender Plattengröße steigende Wahrscheinlichkeit eines Unrecoverable Read Error (URE). Auf diese Problematik wird am Rande auch in diesem Artikel eingegangen. Allerdings scheint RAID5 bei den Autoren noch immer das System der Wahl zu sein. Das erscheint mir nicht zeitgemäß.

mfg. Thomas

--84.179.179.186 20:32, 13. Okt. 2013 (CEST)

Ob abgeraten wird weiß ich nicht, aber dafür, dass die Unterstützung weitgehend eingestellt wurde, seher ich keien Hinweise. Hier unterstützen z.B. derzeit 168 von 204 Artikeln RAID5 und 150 RAID50, noch häufiger wird nur die Raidlevel 0, 1 (je 202 Artikel, für die verbleibenden 2 sind wahrscheionlich einfach dort keine Daten vorhanden) und RAID10 (187 Artikel). Daher über 82% unterstützen RAID5 und über 73% RAID50, das schaut für mich nicht nach einer weit verbreiteten Einstellungd er Unterstützung aus. --MrBurns (Diskussion) 05:57, 14. Okt. 2013 (CEST)

Mit Anbieter sind eher IBM, Dell, Red Hat usw. gemeint:

http://en.community.dell.com/techcenter/b/techcenter/archive/2012/08/14/new-equallogic-raid-tech-report-considerations-and-best-practices-released.aspx#comments

http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162

Tenor ist: RAID5 ist gefährlich und wird mit zunehmender Größe der Platten gefährlicher. Der englischsprachige Wikipedia-Artikel geht übrigens aus meiner Sicht auch differenzierter auf die Problematik ein. Ist doch ein wichtiger Aspekt bei der Konzeptionierung zumindest wenn man ein neues RAID einrichtet und der Artikel liest sich ein wenig so, als wäre RAID5 die technisch beste Lösung. --84.179.184.109 08:30, 16. Okt. 2013 (CEST)

Ob davon abgeraten wird ist die eine Frage, die andere ist, ob es nicht mehr angeboten wird. Laut deinem Link von Dell ist jedenfalls sowohl RAID5 al auch RAID50 noch konfigurierbar, RAID 5 nur mehr über CLI, nicht mehr über GUI, was aber für diesen Artikel irrelevant ist. --MrBurns (Diskussion) 08:34, 16. Okt. 2013 (CEST)

Es geht mir nicht um die Frage, ob und wie man ein RAID 5 noch mit welcher Hard- oder Software einrichten kann. Es geht nur um den Fakt, dass es (schon seit geraumer Zeit) nicht mehr "best practise" ist. Es geht darum, dass es wichtige und triftige Gründe gibt, die dagegen sprechen mit heute gängigen Festplatten (>1TB) ein RAID 5 neu einzurichten. Und es geht darum, dass diese Problematik in einem differenzierten Wikipedia-Artikel Erwähnung finden sollte.

Die Gründe und Hintergründe sind in dem ebenfalls verlinkten Artikel aus meiner sicht ausreichend erklärt. Auch findet man jede Menge Informationen dazu auf einschlägigen Sites (inklusive der englischsprachigen Wikipedia).

Schlussendlich ist es mir ehrlich gesagt egal, ob die Information aufgenommen wird. Es erschien mir nur wichtig. Ich würde jedenfalls kein RAID 5 oder ähnliches verwenden. Die Vorteile wiegen die Nachteile nicht (mehr) auf. --84.179.166.226 20:04, 16. Okt. 2013 (CEST)

Reihenfolge

RAID 3 ist offenbar simpler als RAID 5. Von daher sollte zuerst RAID5 3 behandelt werden und dann RAID3 5. --Itu (Diskussion) 22:19, 28. Dez. 2013 (CET)

Also das Argument versteh ich nicht ganz. Normalerweise behandelt man eher zuerst das einfachere, dann das komplexere. Allerdings ist hier ohnehin nach Gebräuchlichkeit geordnet, was ich für eine Enzyklopädie für besser halte (solange man das simplere nicht braucht, um das komplexere zu verstehen, aber RAID5 kann man ja problemlos verstehen ohne zu wissen, was RAID3 ist). --MrBurns (Diskussion) 02:26, 29. Dez. 2013 (CET)

Ich habs nur vertauscht, natürlich soll zuerst das einfache, dann das kompliziertere behandelt werden. Die Ordnung nach Gebräuchlichkeit ist nicht so das stechende Kriterium. --Itu (Diskussion) 07:16, 30. Dez. 2013 (CET)

Ich bin mit der jetzigen Reihenfolge auch nicht sehr zufrieden. Man sollte vielleicht sagen, dass RAID 0, 1, 5 die debräuchlichsten RAIDs sind und dann alle RAIDs (numerisch sortiert) beschreiben. Da RAID 5 eine Erweiterung von RAID 4 ist, welches wiederum eine einfache Erweiterung von RAID 3 ist, macht es meiner Meinung nach wenig Sinn, zuerst RAID 5 und danach RAID 3 und RAID 4 zu erklären. --V4len (Diskussion) 14:57, 12. Jan. 2014 (CET)

- 2014 -

RAID 4 & DP

Die Infos zu RAID 4 scheinen mir im besten Fall ungenau zu sein. Der eigentliche Vorteil den RAID 5 gegenüber 4 brachte war eine verbesserte Leseperformance, da beim Lesen die Parityplatte im RAID 4 nur sinnlos mit dreht. Wenn man jetzt bedenkt, dass zu den Anfangszeiten solche Raids oft nur 4 oder 5 Platten umfassten, dann haben wir hier einen Performanceverlust von 20 oder 25% zu beklagen. Daher die Weiterentwicklung.

Was mir auch fehlt ist der große Vorteil von RAID 4. Nämlich die stressfreie Erweiterung desselben. Während RAID 5 Systeme gerne mal Stunden oder Tage dafür brachen ist ein RAID 4 faktisch sofort erweiterbar.

Dieser Vorteil zieht sich auch ins RAID DP von Netapp. Der Abschnitt zum Thema Anzahl Disks im RAID scheint mir auch veraltet:

RAID 6 (RAID-DP)

SAS und FC: 28 (26 Datendisks plus 2 Parity-Disks) 
SATA: 20 (18 Datendisks plus 2 Parity-Disks) 

RAID 4 
FC: 14 (13 Datendisks plus 1 Parity-Disk) 
SATA: 7 (6 Datendisks plus 1 Parity-Disk) 

Quelle : http://www.netapp.com/de/products/storage-systems/fas3200/fas3200-tech-specs.aspx

Originaltext: "RAID-DP-Sets bestehen in der Regel aus 14 + 2 Platten. Somit liegt der Brutto-Netto-Verschnitt ähnlich niedrig wie bei RAID 4/RAID 5." (nicht signierter Beitrag von Nevis Latan (Diskussion | Beiträge) 11:16, 15. Jan. 2014 (CET))

Es ist mir nicht klar, in wieweit der einleitende Satz etwas mit dem Rest Deines Kommentars zu tun hat. Welche Informationen zu RAID 4 sind ungenau? Die verbesserte Leseperformance wird in dem Artikel ja thematisiert. --V4len (Diskussion) 11:54, 15. Jan. 2014 (CET)

Hier: "Ein Nachteil bei klassischem RAID 4 besteht darin, dass die Paritätsplatte bei allen Schreib- und Leseoperationen beteiligt ist. " Warum sollte, bei einem intakten Raid die Parityplatte gelesen werden? Schreiben ja, geht ja nicht anders, aber Lesen nein. Was ja auch richtig im Artikelteil zu RAID 5 steht : "Da die Paritätsinformationen beim Lesen nicht benötigt werden, stehen alle Platten zum parallelen Zugriff zur Verfügung."

Und der Satz hier: "Dadurch ist die maximal mögliche Datenübertragungsgeschwindigkeit durch die Datenübertragungsgeschwindigkeit der Paritätsplatte begrenzt." Ist damit höchstens für Schreiben gültig. (nicht signierter Beitrag von Nevis Latan (Diskussion | Beiträge) 00:40, 16. Jan. 2014 (CET))

Das ist schon etwas konkreter :) In der Tat wäre das ja einfach zu editieren. Viel Erfolg --V4len (Diskussion) 09:40, 16. Jan. 2014 (CET)

Weniger gebräuchliche oder bedeutungslos gewordene RAID-Level

Raid 2 und 3 sind hier sicher richtig untergebracht, aber 4 und DP sind die einzigen Raidlevel die einer der großen Player im Storagemarkt nutzt. Und zwar ausschließlich. Daher würde ich um eine Umsortierung im Artikel bitten. (nicht signierter Beitrag von Nevis Latan (Diskussion | Beiträge) 00:40, 16. Jan. 2014 (CET))

Im Allgemeinen habe ich Probleme mit dem Abschnitt Weniger gebräuchliche oder bedeutungslos gewordene RAID-Level. Das führt immer dazu, dass der Abschnitt überarbeitet werden muss. Besser fände ich

• Auflistung aller klassischen RAID-Levels (0-6), die lediglich theoretisch erklärt werden (Lesen/Schreiben/Platte Austauschen/Platte Hinzufügen)
• Ein Abschnitt, der die RAID-Levels unter praktischen Gesichtspuntken beschreibt (Welche Anwendung ist optimal für welches RAID / Was sind handelsübliche RAIDs inkl. Unterscheidung zwischen Consumer-RAID und Business-RAID)

Aber vermutlich sieht das jeder etwas anders. Ich bin sehr gespannt, wie Du den Artikel umschreibst. Viel Erfolg.

--V4len (Diskussion) 09:37, 16. Jan. 2014 (CET)

Ausfallwahrscheinlichkeit RAID5

Da ein RAID 5 nur dann versagt wenn mindestens zwei Platten gleichzeitig ausfallen, ergibt sich bei einem RAID 5 mit n+1 Festplatten eine Ausfallwahrscheinlichkeit von 1-((1-p)^n(1+p\cdot{n})), falls die Ausfallwahrscheinlichkeit p einer Festplatte statistisch unabhängig von den übrigen Festplatten und für alle Festplatten identisch ist.

Bei diesem Textabschnitt besteht eine nicht genannte implizite Annahme, welchen Zeitraum man als "gleichzeitig" versteht. Eine sinnvolle Definition für Gleichzeitig wäre die Zeitspanne t, die für Ersatz der (ersten) defekten Platte incl. interner Reorganisation des RAID benötigt wird (z.B. 1 Tag). Ist die angegebene Formel korrekt, wenn man die Ausfallwahrscheinlichkeit p (pro Zeiteinheit T, z.B. 1 Jahr) auf diese Zeitspanne t umrechnet ? (nicht signierter Beitrag von 80.152.134.114 (Diskussion) 14:07, 28. Jan. 2014 (CET))

Tabelle fehlerhaft

Irgendwelche Funktionen sind nicht mehr funktionierend in der RAID Tabelle.

--82.210.228.3 08:49, 7. Feb. 2014 (CET)

Kann man das bitte etwas konkreter formulieren? Welcher Abschnitt, welche Tabelle, welche Funktion? --V4len (Diskussion) 09:26, 6. Mär. 2014 (CET)

Beispiel Rechnung

Wieso nimmt man für den Beispiel 3 HDD? Es ist völlige swachsinn, weil es am ende so aussieht, ob RAID1 3 mal viel Platz einnimmt, als ob ohne, was zu eine Fehl entscheidung führen könnte. (nicht signierter Beitrag von 37.201.79.143 (Diskussion) 08:51, 6. Mär. 2014 (CET))

Kannst Du das bitte etwas konkreter formulieren? Auch das Benutzen der deutschen Grammatik und Orthographie wäre teilweise hilfreich. --V4len (Diskussion) 09:28, 6. Mär. 2014 (CET)

Trotz etwas unglücklicher Formulierung dürfte nicht so schwer zu erkennen sein, dass gemeint ist, dass bei RAID1 mit drei Platten eine Platte ungenutzt bleibt (was in der Tat ziemlich idiotisch ist) und die Spieglung deswegen besonders schlecht wegkommt (nämlich 1 TB bei Einsatz von 3 TB, bzw. Nutzungsgrad 33 %). Es hätte also entweder statt RAID 1 RAID 1E verwendet werden müssen, oder das Beispiel hätte (besser) mit 4 Platten à 1 TB gerechnet werden sollen. (Eigentlich hätte das dem Schreiber selbst auffallen müssen ;-) --212.202.110.199 23:15, 28. Mär. 2014 (CET)

Wieso wird eine Platte nicht genutzt? Alle Platten werden genutzt. RAID1 bei 3 Platten macht durchaus Sinn, wenn einem die Plattensicherheit sehr wichtig ist. Wieso sollte man 4 Platten benutzen. Beim RAID1 würde das zu einem Nutzungsgrad von 25% führen. Deine Argumentationskette ist hier etwas inkonsistent oder Du wolltest etwas anderes sagen als Du geschrieben hast. --V4len (Diskussion) 13:19, 29. Mär. 2014 (CET)

Unklare Formulierung RAID 1

"Eine Spiegelplatte ist kein Ersatz für eine Datensicherung, da sich auch versehentliche oder fehlerhafte Schreiboperationen (Viren, Stromausfall, Benutzerfehler) augenblicklich auf die Spiegelplatte übertragen. Dies gilt insbesondere für unvollständig abgelaufene, schreibende Programme (etwa durch Stromausfall abgebrochene Update-Transaktionen auf Datenbanken ohne Logging-System), wobei es hier nicht nur zu der Beschädigung der Spiegelung, sondern auch zu einem inkonsistenten Datenzustand trotz intakter Spiegelung kommen kann. Abhilfe schaffen hier Datensicherungen und Transaktions-Logs."

augenblicklich ist leider in diesem Fall eine unklare schlechte Formulierung, mir fehlt die tatsächliche zeitliche datenbeschreibung der HDDs untereinander mit Referenz! --Nobodystranger (Diskussion) 12:30, 2. Okt. 2014 (CEST)

Wieso steht RAID6 unter der Überschrift für unübliche Varianten?

Wird das wirklich so wenig eingesetzt? Wenn ja, verstehe ich es nicht ganz und halte es für grob fahrlässig, dass stattdessen RAID5 verwendet wird. --StefanRing (Diskussion) 13:51, 24. Apr. 2014 (CEST)

Ich halte die Unterscheidung in übliche und unübliche RAID-Levels grundsätzlich für problematisch. Ich fände es besser, wenn man die einfachen RAID-Systeme RAID0 bis RAID6 in einem Abschnitt (mathematisch) beschreibt und danach über Vor- und Nachteile der einzelnen RAIDs spricht. Andernfalls muss man immer wieder den Artikel bzgl. seiner "Üblichkeit" bearbeiten. --V4len (Diskussion) 10:28, 28. Apr. 2014 (CEST)

RAID5 ist schon länger nicht mehr "best practise". RAID6 ist der designierte Nachfolger, der die durch wachsenden Kapazitäten entstandenen Probleme lösen sollte... Aber so ist das mit Glaubenssätzen. --77.179.208.111 08:39, 11. Dez. 2014 (CET)

RAID 3

Im Abschnitt zu RAID 3 steht, dieses sei "inzwischen vom Markt verschwunden und [sei] weitgehend durch RAID 5 ersetzt". Das stimmt so allerdings nicht, es gibt durchaus einige (auch kommerzielle) Lösungen am Markt, die RAID 3 einsetzen. Genannt seien Snapraid (http://snapraid.sourceforge.net) und Flexraid (http://www.flexraid.com). Snapraid bietet allerdings keine Echtzeitfunktion, Flexraid hingegen schon.

Den angegebenen Nachteil ("Damit ergibt sich auch gleich der größte Nachteil: Die Paritätsplatte wird bei jeder Operation, vor allem Schreiboperation, benötigt, sie bildet dadurch den Flaschenhals des Systems") kann ich ebenfalls teilweise nicht nachvollziehen. Warum sollte bei Lesezugriffen immer auf die Paritätsplatte zugegriffen werden müssen? Meines Wissens ist dies zwangsläufig nur bei schreibenden Zugriffen nötig, die zudem die Prüfsumme ändern (was aber in der Regel der Fall sein wird).

Gerade wenn nur große Mengen an Daten gespeichert werden sollen, hat RAID 3 den Vorteil, dass Festplatten quasi beliebig ausgetauscht werden können, unterschiedliche Festplattengrößen verwendet werden können (nur die größte Platte muss immer die Paritätsdaten speichern) und bei einem Verlust Platten über die Recovery-Grenze hinaus bleiben zumindest die anderen Platten lesbar. Ich finde man sollte diese Vorteile ebenfalls erwähnen, ansonsten ist der Artikel nicht wirklich neutral gehalten.

Wie sieht ihr das? --88.152.214.16 09:36, 30. Okt. 2014 (CET)