[Übersicht] Der RAID0-Katastrophen-Thread

[Mirador]

Nachdem immer wieder Probleme mit RAID0-Fehlern auftreten, hier mal eine Linksammlung der jüngsten Vergangenheit. Es gab in diesem Jahr noch viel viel mehr, also falls noch jemand Links hat...

All denen, die ein RAID0 aufsetzen wollen aber keine Bakups anfertigen, sei dies Mahnung und Abschreckung.
All denen, die bereits im Regen stehen, nützt vlt. die Erfahrung der anderen - oder ist zumindest ein Trost.

14.11.2008, Raid 0 Wiederherstellen
31.10.2008, Problem mit Raid0 -> Mainboardwechsel :-/
16.10.2008, Raid Volume defekt
12.10.2008, Raid 0 auf neuemMainboard ?
12.10.2008, Raid 0 zeigt Fehler
10.10.2008, Raid 0 Datenrettung
06.10.2008, Raid0 @ Intel ICH8R - Eine HDD beschädigt??
17.09.2008, Kaputtes Raid 0 - Daten retten?
16.09.2008, Raid0 Dell Perc5/i drive missing bzw. ready

Wird fortgesetzt.


Noch ein Wort zum Thema "Geschwindigkeit"
Die Legende um die performancesteigernde Wirkung eines RAID0 hält sich Dank der guten Benchmarkergebnisse hartnäckig, hat aber mit der Praxis nichts mehr zu tun.

Der Grund ist, dass in der Vergangenheit die Datentransferraten drastisch gestiegen sind, die Zugriffszeiten sich aber allenfalls um ein paar Prozent verbessert haben. Man merkt dies sofort, wenn man versucht, die ideale Stripe Size für das RAID0 einzustellen:

Bei einer angenommenen Zugriffszeit von 10ms (die viele Platten nicht einmal erreichen) und 100MB/s Leserate müsste die Stripe Size schon 1MB betragen, denn nur dann ist 100%ig sicher gestellt, dass beide Platte kontinuierlich wechselseitig Daten liefern.
Zu Anfang fällt die Zugriffszeit auf jeden Fall einmal an, und da beide Platten parallel arbeiten, können sie (statistisch betrachtet) gleichzeitig Daten liefern.
Aber spätestens wenn der dritte Stripe gelesen wird (dann wieder von der ersten Platte) muss die volle Zugriffszeit abgewartet werden.

Eine Stripe Size von 1MB bedeutet aber, dass die meisten Dateien innerhalb eines Stripes liegen, und damit die Datentransferleistung der zweiten Platte gar nicht zum Tragen kommt (immer unter der Voraussetzung, dass der Controller eine Stripe Size dieser Größe überhaupt zulässt).

Wer also nicht ständig mit rießigen Dateien hantiert, hat performancemäßig nichts von seinem RAID0.
Benchmarks tun übrigens genau das (mit rießigen Dateien hantieren), um die Wirkung von Caches zu egalisieren; mit kleinen Dateien haben die schnellen Zwischenspeicher zu viel Einfluss auf das Meßergebnis. Im Endeffekt sind normale Festplattenbenchmarks damit nur noch zur Bestimmung der Rohleistung brauchbar; praxisrelevantere Ergebnisse erhält man nur mit vergleichsweise komplexen Werkzeugen wie IOMeter.

Lesenswert hierzu ist auch der Post von HisN: *klick*

Lösung 1: SSDs
SSDs haben eine um Faktor 100 niedrigere Zugriffszeit und sind daher heiße Kandidaten für ein RAID0. Leider gilt dies nur für Lese- und nicht für Schreibvorgänge, zudem sind sie noch extrem teuer pro GB.
SSDs organisieren ihre Zellen zeilenweise (z.B. 128kB) und eine Zeile muss immer komplett geschrieben werden, weshalb idealerweise die Stripe Size in der entsprechenden Größe gewählt werden sollte.

Lösung 2: viele Festplatten
Ein RAID0 kann man mit beliebig vielen Platten betrieben - soviel wie der Controller Anschlüsse bietet. Bei z.B. 16k SS und 16 Platten profitiert man bei Dateigrößen von 16k-256k vom RAID0, bevor dann das Zugriffszeitproblem zuschlägt. Das Ausfallrisiko ist natürlich entsprechend.

Noch ein Wort zur Zugriffszeit: viele User berichten, dass im RAID0 die Zugriffszeit höher ist als beim Zugriff auf eine Einzelplatte. M.M. nach liegt dies am Controller, denn bei mir ist mit 4 Platten im RAID0 die Zugriffszeit sogar etwas niedriger. Allerdings: wer wird schon für ein RAID0 einen 250€ Controller anschaffen?

Auch noch praktisch: die Kapazitätserweiterung
Neben dem Performanceaspekt ist es natürlich ganz praktisch, dass man durch zusätzliche Platten einfach die Kapazität erweitern kann. Angesichts der Ausfallwahrscheinlichkeit muss man aber zu einem RAID5 raten, welches aber nur mit dezidiertem Controller erträglich ist. Ein Kompromiss aus "schnell" und "sicher" ist ein RAID10, da sind wir dann aber schon bei mindestens 4 Platten angelangt.
"Größere Platte kaufen und alte verkaufen" dürfte daher für die Meisten die beste Variante zur Kapazitätserweiterung sein.

 

[gnaa123]

gute idee
ich würde die schriftgröße erhöhen und den text rot färben

 

[xymon]

raid-katastrophen thread ist schon was interessantes machst du das dann auch für raid 1,...

mfg xymon

 

[Mirador]

machst du das dann auch für raid 1,...

Nö, die anderen RAID-Level haben ja das "R" im Namen verdient.
Mir geht es vor allem um die Leute, die unbedingt ein RAID0 haben wollen, ohne richtig zu wissen, worauf sie sich einlassen. Eine Präventivmaßnahme sozusagen.

Und ein "Fehlendes-Backup-Katastrophen-Thread" wäre mir dann doch zu viel Arbeit.

 

[A_H]

Dort habe ich versucht anzudeuten, wo Knackpunkte sind:

http://www.forumdeluxx.de/forum/showthread.php?t=540831

Nachdem mein Raid0 nach Stromausfall hin war, habe ich den Controller nur noch für eine Sata-Platte genommen. Das lief einwandfrei bis zu dem Tag, als ich das Kabel mal auf einen anderen Stecker an der Karte gesteckt habe. Ich habe mich monatelang gewundert, anderes Bios, anderen Treiber usw. installiert.

Nur das zusätzliche Stück Hardware bringt schon zusätzliche Unklarheiten und Risiko.

TÄUSCHT EUCH NICHT!
Jedes Raid, außer Raid1, trägt das Raid0 in sich.

 

[A_H]

Das ist wirklich Scheiße!

Scheiße...du hast recht Snoopy69.
NEIN!...hmm...toll dann muss ich jetzt das Mainboard zurück schicken und mir das andere bestellen! Mist...! Echt blöd gelaufen^^

Oder sollte ich mir lieber einen extra Controller leisten? Was kosten sonne teile?

Da war wieder jemand zu blöd, die Kurzinformation von seinem Board vor dem Kauf zu lesen!

Dann kann man auch nicht ausschließen, dass der nicht weiß, wie man ein Mainboard bzw. jegliche Elektronik behandelt und es beschädigt zurück schickt und der nächste Käufer damit angeschmiert wird.

Und dann meckern die Dumpfbacken wieder über diesen oder jenen Hersteller.

Und ich wundere mich über meinen zickigen Controller.

Sowas stinkt mir!

Edit:
Ich habe gerade gelesen, das Board wurde noch nicht geliefert und soll (ungeöffnet) zurück. Aber es gibt hier tausend andere solcher Fälle.

Gibt es nur einen einzigen Bericht über ein echt zerstörtes Raid von dem wenigstens ein Teil der Daten gerettet wurde?

 

[gnaa123]

kein Tag ohne Raid0 Threads

Eine Erklärung / Ein paar Links zum Thema Geschwindigkeits Vorteil/Nachteil in Post 1 wäre noch sinnvoll finde ich. Vielen erstellen wohl aus Unwissenheit ein Raid 0 obwohl es für ihren Anwendungsbereich gar keinen Geschwindigkeitsvorteil bringt sondern eher noch eine Nachteil (Zugriffszeit) hinzu kommt die Sache mit den Backups die fast niemand macht.

 

[A_H]

Für die Sammlung:
http://www.forumdeluxx.de/forum/showthread.php?t=541728

@bnaa123
Es gibt einen RAID Guide:
http://www.forumdeluxx.de/forum/showthread.php?t=119202

Aber das ist immer nur Theorie, die Schemata werden dargestellt. Die praktische Realisierung, die Software, das kommt zu kurz.

Ich fand mein Raid0 schon etwas flotter. Aber ich habe mir Klarheit verschafft, bevor ich es gemacht habe - das ist allerdings auch mein Beruf. Und als es kam, wie es kommen musste, hatte ich mein Backup und habe nicht lange gefackelt. Ich hatte genug gespielt.

Meine Vermutung warum Raid so beliebt ist:
Jeder Dödel kann es erst mal machen und kommt sich dabei großartig vor, als hätte er selbst etwas konstruiert, etwas geleistet - Irrtum.

 

[Mirador]

So, ich habe mal meine Erkenntnisse zum RAID0 im Startposting verewigt.
Den RAID-Guide muss ich nicht verlinken, denke ich, der ist ja eh pinned.

 

[dante`afk]

ich hab da nen problem^^

Asus p5q-e
2x wd caviar blue 640


ich habe gestern alles brav angeschlossen und ein raid0 erstellt, heute morgen war er dann fertig und alles lief gut - auch nach reboot. dann hab ich den pc ausgeschaltet und bin zur arbeit gefahren.

jetzt komm ich heim und er lädt das OS nicht mehr.. nachdem er den raid gecheckt hat ohne fehler ( normal 1 / 2 - bootable etc ) kommt irgendwie vista loader 2.1.2 - couldnt load vista---fallback 1... fallback 2 und er lädt das Grub4Dos - hm was ist zu tun :< ?

 

[HisN]

Mein Lieblings-Rechnenbeispiel um den Unterschied und die Gewichtung von Zugriffszeit und Dauertransferrate zu zeigen.

Du lädst 1000 32kb-Dateien beim Windows-Start aus dem System32-Verzeichnis (oder beim Programmstart, das ist nicht weit hergeholt, schau auf Deine Platte bzw ins Photoshop-Verzeichnis)

60MB/sec 12MS-Platte: 1000 Kopfbewegungen: 12 Sekunden. 32MB Daten laden: 0,5 Sekunden
Dein Raid0 120MB/12MS: 12 Sekunden Kopf, 0,25 Sekunden Daten

Lutscher CF-Card an IDE-Adapter. 32MB/sec und 0.3ms
0.3 Sekunden Kopf, 1 Sekunde Daten
OCZ Core mit 120MB/sec und 0.3ms: 0.3 Sekunden Kopf und 0,25 Sekunden Daten

DAS ist der Unterschied den die Raid0-Jünger nie Begreifen werden. Raid0 Popelt am falschen Ende.

Eine SSD starten Photoshop so fix, als würdest Du es als Platten-Benutzer zum 2. mal starten (wo es ja komplett aus dem Datenträger-Cache kommt).

Andersrum: Wenn Deine Photoshop-Dateien 512MB und größer sind.... da würde sich das Raid "lohnen", weil da große Dateien am Stück geladen werden wo die S/L-Köpfe nicht fahren müssen.

Ist natürlich schwer abstrakt, weil sicherlich nicht jedesmal 1000 Dateien geladen werden müssen, und bestimmt auch einige davon innerhalb eines Stripes liegen und der Kopf nicht neu positioniert werden muss, aber es macht deutlich was wirklich wichtig ist. Das die CPU zwischenzeitlich vielleicht noch was mit den geladenen Dateien anstellen muss und deshalb der Lade-Prozess unterbrochen wird lass ich mal ganz außen vor^^

http://www.storagereview.com/php/cms/cms.php?loc=news_content&id=970&start=6&range=10
http://anandtech.com/storage/showdoc.aspx?i=2101&p=10
http://anandtech.com/storage/showdoc.aspx?i=2974&p=5

Offizielle Quellen

 

[7oby]

Man merkt dies sofort, wenn man versucht, die ideale Stripe Size für das RAID0 einzustellen:

Bei einer angenommenen Zugriffszeit von 10ms (die viele Platten nicht einmal erreichen) und 100MB/s Leserate müsste die Stripe Size schon 1MB betragen, denn nur dann ist 100%ig sicher gestellt, dass beide Platte kontinuierlich wechselseitig Daten liefern.
Zu Anfang fällt die Zugriffszeit auf jeden Fall einmal an, und da beide Platten parallel arbeiten, können sie (statistisch betrachtet) gleichzeitig Daten liefern.
Aber spätestens wenn der dritte Stripe gelesen wird (dann wieder von der ersten Platte) muss die volle Zugriffszeit abgewartet werden.

Es gibt unzählige Tests zu Strip Sizes. Ich habe keinen gesehen indem Stripesizes um 1MB als ideal ausgemessen wurde. Die Tatsache, dass man in synthetischen Streamingbenchmarks (HDTach, ...) die doppelte Übertragungsbandbreite bei wesentlich kleineren Stripes erreicht, widerlegt obige Aussagen bereits.

Die Modellvorstellung die hier dargestellt wird, entspricht nicht der RAID Implementierungen.

Zugriffszeit = Seektime + Latenzzeit
Seektime = Zeit zum Bewegen des Schreib/Lesekopfes
Latenzzeit = warten bis Sektor unter dem Schreib/Lesekopf vorbeifliegt

Mal ins Datenblatt einer beliebigen 7200 U/min Platte geschaut (hier 1TB F1):
http://www.samsung.com/global/busin...72&type=61&subtype=63&model_cd=249&ppmi=1155#

Average Latency = 4,17ms = 1/2 * (1/7200) * 60s
Average Seek time(typical) = 8,9ms

In obigem Posting wird behauptet, dass die Average Latency (bzw. in seinem Fall sogar 2x Average Latency für eine Umdrehung) anfällt bei jedem 2. Stripe lesen. Das ist sebstverständlich nicht der Fall.

Einfaches Beispiel:
. RAID0 mit 2 Festplatten
. stripesize : 32kb
. no_read_sectors : Anzahl der zu lesenden Sektoren

. DIV = Ganzzahl Division
. MOD = Modulo Operation
. ceil() = Aufrundungsfunktion

Dann berechnen folgende drei Zeilen die zu lesenden Stripes pro Festplatte:
no_stripes = ceil(no_read_sectors / stripesize)
drive0_stripes= no_stripes DIV 2 + no_stripes MOD 2
drive1_stripes = no_stripes DIV 2

Kann ohne Probleme auf RAID0 mit beliebig vielen Platten und mit Startsektor offsets verallgemeinert werden.

Es ist also trivial auszurechnen welche Platte wieviele Sektoren zu lesen hat und diese werden natürlich am Stück angefordert. Bzw. Modulo der Busmaster Übertragungsblöcke. Mit nichten wird jeweils zwangsweise die Latenzzeit abgewartet, da der Nachfolgelesebefehl noch nicht bereit stand.

Als Stripesizes werden sinnvollerweise Vielfache der Filesystem Clustergröße (4kb bei NTFS) gewählt. Die Fragmentierung einer Datei ändert nichts großartig an obiger Betrachtung.

--

Ich will hier gar nicht pro/contra RAID0 schreiben.

Habe mich über den sticky Post RAID Guide hier im Brett sehr gewundert. Ziemlich veraltet und bestensfalls Wikipedia-KnowHow Level (zudem hätte man gleich verlinken können - viel mehr steht im Guide nicht drin).

Antworten auf folgende Fragen wären wesentlich interessanter gewesen:
. Wie zuverlässig sind Host-RAID Controller im Vergleich zu Hardware-RAID Controllern? Mal einen Blick in die Known Issue Liste der intel Matrix Storage Treiber werfern: v8.5.0.1032 vom 29. Juli 2008; v8.6.0.1007 vom 3. Oktober 2008. Server verwenden auch kein Syspend, Hibernate - eine ständige Fehlerquelle für (Host Controller-) Treiber.
. Wie relevant sind RAID Edition Festplatten mit Features wie TLER für Desktop Host RAID Konfigurationen. Praxiserfahrungen sind hier gefragt - nicht die Technik an sich.
. Die statistische Betrachtung von Ausfallwahrscheinlichkeiten auf MTBF Basis ist völlig irrelevant für Desktop RAID Systeme. Auf Desktop Systemen gibt es eine Reihe von zusätzlichen Fehlerquellen (Treiber, Systemabstürze, Kabel, Ram!). Desktopsysteme sind in meinen Augen anfälliger für RAID-Rebuilds. Und da macht es natürlich schon einen Unterschied ob ich ein RAID5 oder RAID1 fahre. Sogesehen kann ich ein RAID5 für ein Desktop System nicht unbedingt empfehlen (auch wenn's genügend System gibt, bei denen es fehlerfrei läuft). Bei einem Hardwarde Controller mit RAID Edition Festplatten aus der Kompatibilitätsliste des Herstellers hätte ich bei einem RAID5 hingegen kaum Bedenken (neben den üblichen RAID5 Problemen).

 

[Mirador]

Der Satz:

Die Fragmentierung einer Datei ändert nichts großartig an obiger Betrachtung.

ist eben völlig falsch, denn er ändert alles.
Deine Formel rechnet nur aus, wieviele Stripes einer Datei auf welcher Platte liegen; und selbstverständlich werden die auch "am Stück angefordert".

Das sagt jedoch nichts darüber aus, ob die Platte eine Kopfbewegung machen muss, um zum nächsten zu lesenden Stripe zu gelangen oder nicht!

Dein Szenario geht von einer vollständig defragmentierten Platte aus, ebenso Dein Benchmark-Beispiel: Benchmarks werden mir leeren Platten gefahren und schreiben dann natürlich unfragmentierte Daten, die sich auch entsprechend schnell wieder lesen lassen.
Steht nicht gleich im ersten Satz meines Postings, dass RAID0 in Benchmarks gut aussieht? Und steht dort nicht auch gleich, dass die von Dir angeführten "synthetischen Streamingbenchmarks" mit dem Arbeitsalltag nicht mehr viel zu tun haben?

Wenn man 100%ig sicher stellen will, dass das RAID0 perfekt funktioniert (und davon habe ich geschrieben), muss man davon ausgehen, dass der logisch benötigte Folge-Stripe eben nicht der physikalisch vorhandene Folge-Stripe ist. Selbstverständlich ist das nicht "zwangsweise" der Fall, aber auf einer Platte, die lediglich Windows-Defragmentierung verwendet, eher die Regel als Dein Szenario.

Meine Aussage ist: RAID0 funktioniert um so besser, je niedriger die Zugriffszeit ist, zwei Beispiele habe ich genannt. Defragmentierung vermindert in dem Sinne auch die Zugriffszeit, da Kopfbewegungen im Idealfall eleminiert oder zumindest stark reduziert werden.

Dass aber die Zugriffszeit keinen Einfluss auf die Performance haben soll - nicht anders bedeutet der Satz "Die Fragmentierung einer Datei ändert nichts großartig an obiger Betrachtung" - ist schon vom gesunden Menschenverstand her unmöglich.

 

[A_H]

Diese Einzelheiten werden die hiesigen Anfänger und Laien, die sich zu Raid0 oder 5 berufen fühlen, ja doch kaum interessieren. Das letzte Drittel von 7obys Beitrag scheint mir wichtig und mit etwas gutem Willen auch leicht verständlich. Das entspricht auch meiner Ansicht.

Aber die Kids wollen nicht nachdenken und kalkulieren. Die wollen nur blindlings endlich auch ihr RRRAAAIIID!

 

[7oby]

Das stimmt nicht und war der Hauptkritikpunkt von mir:

Bei einer angenommenen Zugriffszeit von 10ms (die viele Platten nicht einmal erreichen) und 100MB/s Leserate müsste die Stripe Size schon 1MB betragen, denn nur dann ist 100%ig sicher gestellt, dass beide Platte kontinuierlich wechselseitig Daten liefern.

Das Filesystem NTFS (u. auch FAT32) weiß nichts von Stripsizes (wird sind hier nicht bei ZFS). Deshalb ist die Datei so fragmentiert wie sie eben ist. Und nehmen wir exemplarisch an die Fragmentgröße eines firefox.exe wäre 512kb. Also alle 512kb ein neues Fragment (das entspricht 128 Cluster a 4kb in NTFS). Das nehmen wir nur an um das Prinzip zu erläutern. Absolut ohne Anspruch auf realitätsnähe.

Das Filesystem (bzw. eigentlich der Windows Cache Manager, aber verwirrt hier nur) addressiert nun Sektoren. Und 512kb muss der Schreib-/Lesekopf nun neu positioniert werden. Das ist völlig unabhängig von der Stripesize! Die kann auf 1MB stehen oder 16kb. Physikalisch wären die Daten unterschiedlich auf den beiden Volumes verwebt. Die Zugriffsmuster (alle 512kb ein Seek) wären jedoch in beiden Fällen exakt gleich.

Ich hoffe der Unterschied ist diesmal klar geworden. Ich wusste nicht welchen Teil vom Softwarestack missverstanden wurde (und alles mag ich auch nicht erklären). Und hatte halt den unteren Teil erklärt wie man von den Sektoren (die das Filesystem anfordert) auf die Stripes kommt.

Die Stripesize hat vor allem Auswirkungen auf die Anzahl der I/O Befehle. Und damit auf die Hardware-Controller Last bzw. CPU Last im Falle eines Host-Controllers. Damit sinkt/steigt die Performance abhängig von der Stripesize. Anwendungen spielen für die Stripesize auch eine Rolle.

Wo ich gerade dabei bin: Hast ja geschrieben, dass die Zugriffszeit beim RAID0 bei Dir nicht höher ist (gemessen wohlgemerkt!). Und da gibt's so komische Typen, die behaupten sie wäre größer beim RAID0. Dieses Paradoxon kann man auch ganz einfacher klären, wenn man weiß wie: So'n HDTach, HDTune, Atto etc. liest immer einen (!!!) Sektor und misst die Zugriffszeit. In dem Fall ist bei einer 7200er Platte immer die Average Latency = 4,17ms enthalten (Formel siehe oben). Wenn Du aber von 2 Platten lesen musst ist der Erwartungswert hier (2/3) * (1/7200) * 60s = 5,56ms. Kommt daher, dass die Köpfe unabhängig voneinander warten müssen bis die Sektoren kommen. Das passiert wiederum statistisch dann wenn man Dateien liesst die größer als die Hälfte der Stripesize sind bzw. immer, wenn die Datei größer ist als die Stripesize. Das kriegst halt nicht mit HDTach, HDTune, ... gemessen, die nur immer 1 Sektor (512 Byte) lesen.

Hab' ich jetzt auf alles geantwortet oder was ausgelassen?

 

[Mirador]

Der "Geschwindigkeits"-Teil des Startposting ist geschrieben für Leute, die sich durch ein RAID0 mit normalen Platten einen Performance-Boost erhoffen.
Es geht daher um das, was der Controller im RAID0 tun kann, um die Performance zu steigern, und das ist nun mal ausschließlich das Striping. Wenn die Datenanforderung schon so aussieht, dass der Controller nicht mal einen Stripe komplett auslesen kann, was soll er dann tun? Den Fall braucht man nicht zu betrachten, hierfür wird ein RAID0 (unabhängig von der Zugriffszeit) nie etwas bringen.

Wenn tatsächlich mehrere Stripes eingelesen werden, müsste es doch aber "krachen": tut es aber nicht aufgrund der bei HDs vergleichsweise langen Zugriffszeiten. Ich bleibe dabei: um 100%ig Wartezeiten durch Zugriffswechsel zu vermeiden, müssen die Stripes extrem groß sein (1 MB im genannten Beispiel). Über die Ursachen des Zugriffswechsels habe ich gar nichts geschrieben, ist auch völlig egal: dazu reicht es schon, dass die Datenspur zuende gelesen ist. Ist die Stripe Size kleiner, hat man in vtl. 90% aller Fälle keine Wartezeiten, aber garantiert keine 100% mehr.

Die Stripesize hat vor allem Auswirkungen auf die Anzahl der I/O Befehle. Und damit auf die Hardware-Controller Last bzw. CPU Last im Falle eines Host-Controllers. Damit sinkt/steigt die Performance abhängig von der Stripesize. Anwendungen spielen für die Stripesize auch eine Rolle.

Die Stripe Size alleine hat keine Auswirkung auf "die Anzahl I/O-Befehle", eine Controller-Limitierung gibt es heutzutage nicht mehr. Nur zusammen mit dem Muster der angeforderten Datenblöcke beeinflusst die Stripe Size die IOPS:

A larger stripe size produces better read performance, especially if your computer does mostly sequential reads. However, if you are sure that your computer does random reads more often, select a smaller stripe size.

Wo ich gerade dabei bin: Hast ja geschrieben, dass die Zugriffszeit beim RAID0 bei Dir nicht höher ist (gemessen wohlgemerkt!). Und da gibt's so komische Typen, die behaupten sie wäre größer beim RAID0. Dieses Paradoxon kann man auch ganz einfacher klären, wenn man weiß wie: So'n HDTach, HDTune, Atto etc. liest immer einen (!!!) Sektor und misst die Zugriffszeit.

So ist eben Zugriffszeit definiert. Latenzen bei der Anforderung von nachfolgenden Datenblöcken gehen nicht mehr in die Zugriffszeit ein sondern nur noch in den Durchsatz.

In dem Fall ist bei einer 7200er Platte immer die Average Latency = 4,17ms enthalten (Formel siehe oben). Wenn Du aber von 2 Platten lesen musst ist der Erwartungswert hier (2/3) * (1/7200) * 60s = 5,56ms. Kommt daher, dass die Köpfe unabhängig voneinander warten müssen bis die Sektoren kommen. Das passiert wiederum statistisch dann wenn man Dateien liesst die größer als die Hälfte der Stripesize sind bzw. immer, wenn die Datei größer ist als die Stripesize. Das kriegst halt nicht mit HDTach, HDTune, ... gemessen.

Die Formel verstehe ich nicht und sie ist für die Zugriffszeit auch irrelevant, da hierfür immer nur die Lieferung des ersten Datenblocks des Ausschlag gibt. Die Zugriffszeit eines RAID0 entspricht dem Durchschnitt der durchschnittlichen Zugriffszeiten aller beteiligten Platten.

 

[7oby]

Eins vorweg: Die Aufstellung von RAID0 Fehlerfällen finde ich gut! Also das Thema des eigentlichen Threads hier. Hilft hoffentlich dem ein oder anderen, der vor einer (Fehl-)entscheidung steht.

Ich bleibe dabei: um 100%ig Wartezeiten durch Zugriffswechsel zu vermeiden, müssen die Stripes extrem groß sein (1 MB im genannten Beispiel).

Eine Festplatte hat Sektoren und keine Stripes. Der SATA-(RAID)-Controller fordert Sektoren von der Festplatte und Stripes sind lediglich die Verwaltungseinheit des Controllers.

Wenn Du Dir das Firefox Beispiel in meinem vorangegangenen Posting nochmal genau anschaust, dann wirst Du feststellen, dass:
1. die auf der Festplatte belegten Sektoren im Fall Stripe Size 1MB und 16kb exakt gleich sind (dabei angenommen firefox.exe ist ein vielfaches von 1MB)
2. sämtliche Spurwechsel durch Datenspur Ende bei beiden Stripsize Konstellationen ebenfalls gleich sind.

Mit der Zeitlupenkamera aufgenommen würden die Leseköpfe in beiden Fällen die exakt gleichen Lesebewegungen und Spurwechsel vorziehen.

Das Filesystem legt fest welche Sektoren zu lesen sind. Die Fragmentierung des Filesystems entscheidet wieviel aufeinanderfolgende Sektoren jeweils zu lesen sind und stellt eine Liste von Fragmenten zusammen:

Filesystem -> Fragmentliste

Jedes Fragment enthält einen Startsektor und die Anzahl der zu lesenden Sektoren. Im Fall ohne RAID (AHCI) wird diese Fragmentliste 1:1 weitergegeben (Partitionsoffset kommt noch dazu - hier egal):

Fragmentliste -> SATA-Controller -> Fragmentliste SATA Festplatte

Der SATA Controller verwendet pro Fragment das Kommando DMA READ aus der ATA/ATAPI Spezifikation und übergibt Startsektor und Anzahl zu lesender Sektoren dem Laufwerk. Page 142:
http://www.seagate.com/support/disc/manuals/ata/d1153r17.pdf

Es gibt noch Größenbeschränkungen bei der DMA Übertragung, die bleiben außen vor.

Im Fall des RAID Controllers wird die Fragmentliste in eine Sektorliste ungerechnet. Unter zu Hilfe name der Formel, die ich in meinem 1. Posting angedeutet, aber nicht vollständig ausgeführt habe.

Fragmentliste -> RAID-Controller -> Sektorliste SATA Festplatte

Die Sektorliste sieht selbstverständlich anders aus als im AHCI Fall. Aber: Egal ob Deine Stripesize 16kb oder 1MB ist: Die Sektorliste sieht exakt gleich aus im jeweiligen RAID Fall. Und weil die Sektorlisten gleich sind, sind auch die Zugriffe gleich. Und damit die Zugriffszeiten.

Der Inhalt der Sektoren im 16kb und 1MB Stripsize Fall ist unterschiedlich - sie sind anders verwebt, das erläuterte ich bereits.

In meinem allerersten Posting habe ich versucht zu erklären warum der RAID Controller nicht so dumm ist, wie Du ihn verstanden wissen willst. Eigentlich hätte ich überhaupt nicht so sehr ins Detail gehen müssen und es hätte wohl auch gereicht auf

Read Ahead A Full Stripe From Disk
http://www.tecchannel.de/_misc/img/detailoriginal.cfm?pk=347236&fk=432631&id=il-74304747073374514

zu verweisen. Allerdings hättest Du dann vermutlich gesagt: Das ist ja Controllerabhängig.

So ist eben Zugriffszeit definiert. Latenzen bei der Anforderung von nachfolgenden Datenblöcken gehen nicht mehr in die Zugriffszeit ein sondern nur noch in den Durchsatz.

Es ging hier nie um die Definition von Zugriffszeit, sondern darum, dass die Latenzen beim Dateizugriff im RAID0 steigen. HisN hat die drei bekannten Referenzen in diesem Zusammenhang bereits genannt. Dort wurde nachgemessen wie sich teilweise das RAID0 langsamer verhielt als das Non-RAID. Im Desktop Betrieb wohlgemerkt (im Datenbankbetrieb hätte die RAID0 nicht mal den Hauch einer Chance, da die Datenbanken sehr gut parallel Festplatten bedienen können und das RAID0 durch die "Synchronen" Adressierungen hier nur bremst).

Um diesem Effekt zu erklären musste ich zwangsläufig das Wort Zugriffszeit in den Mund nehmen und mit "Dateizugriffszeit" vergleichen. Das ist doch gerade das paradoxe: Im HDTach ist die Zugriffszeit im RAID0 genauso und doppelte Bandbreite hat's auch, aber XP/Vista booten dauert sogar einen Tick länger beim RAID0.

Die Formel verstehe ich nicht und sie ist für die Zugriffszeit auch irrelevant, da hierfür immer nur die Lieferung des ersten Datenblocks des Ausschlag gibt. Die Zugriffszeit eines RAID0 entspricht dem Durchschnitt der durchschnittlichen Zugriffszeiten aller beteiligten Platten.

Bildliche Erklärung: Ein Festplattenkopf ist über der richtigen Spur positioniert und soll einen zufälligen Sektor lesen. Wie lange muss er durchschnittlich warten? 1/2 Umdrehungszeit. Das sind die 4,17ms.

Zwei Festplattenköpfe zweier RAID0 Festplatten sind über der richtigen Spur positioniert und sollen jeweils einen zufälligen Sektor lesen. Wie lange muss man durchschnittlich warten bis beide ihren Sektor gelesen haben? Nehmen wir den 1. Festplattenkopf der muss wieder durchschnittlich 4,17ms warten. Beim 2. Festplattenkopf ist es nun so, dass der seinen Sektor entweder schon längst gelesen hat oder noch warten muss. Im ersten Fall bleibt's bei der Zugriffszeit von 4,17ms. Im Zeiten Fall wird sie schlechter.

Das kann man mit stochastischen Mitteln ausrechnen kommt 5,56ms raus. Ist die Faltung zweier unabhängiger Zufallsvariablen. Die allgemeine Formel für ein RAID0 mit n Laufwerken: n / (n+1) * (1 / rpm) * 60s.

Steigt n (die Anzahl Deiner RAID0 Laufwerke) so konvergiert dies gegen die doppelte Zeit von 4,17ms nämlich 8,34ms. Dafür gibt's auch eine gute bildliche Erklärung: Wenn Du von vielen RAID0 Laufwerken - sagen wir 12 Stück - einen zufälligen Sektor anforderst, obwohl der Schreib-/Lesekopf schon richtig positioniert ist, dann ist die Wahrscheinlichkeit eben sehr groß, dass bei einem der 12 Laufwerken, der entsprechende Sektor unglücklicherweise gerade vorbeigerutscht ist und man eine gesamte Umdrehung warten muss.

Was hat das mit der Praxis zu tun? Ganz einfach: Du forderst eine Datei an, die Daten von beiden Stripes benötigt. Bei einer typischen Stripesize von 64kb ja gar nicht sooo unwahrscheinlich. Nehmen wir das 7200 U/min RAID0 mit 2 Festplatten. Dann passiert eines dieser beiden Dinge (entweder oder).

a) Platte 1 muss nach dem Positionieren durchschnittlich 4,17ms warten. 0,64ms später sind bei 100MB/s die 64kb des 1. Stripes gelesen. Die Uhr steht bei 4,81ms. Und kann Platte 2 schon liefern? Nein sie kann es nicht. Das wäre erst bei 5,56ms (statistisch, durchschnittlich) der Fall. Die Datenübertragung pausiert zwischen 4,81ms - 5,56ms.

b) Platte 2 hat ihre Daten zuerst. Platte 1 unglücklicherweise erst später. Der RAID Controller hat sich die Daten von Platte 2 natürlich sofort gezogen. Ans Betriebssystem kann er jedoch erst anfangen zu übertragen, wenn er auch den Start von Platte 1 hat, denn das war der Anfang der angeforderten Sektorliste. Wieder bei 5,56ms.

 

[Mirador]

Arrrgh, das wächst sich ja immer mehr aus, hier!
Komme gerade nicht zum antworten; wenn's dumm läuft, erst wieder am WE.

 

[IronAge]

Battle of the nerds.

Machts doch wie in der Steinzeit: Zwei Keulen und Hau drauf.

 

[rompen2k4]

nicht aufhören 7oby, ich hab schon lange nicht mehr so viel gelernt. (kein scherz)

 

[IndianaX2]

Darum Raid 0 nur mit SSD's :-P da fällt das mit der Zugriffsgeschwindigkeit nicht mehr auf.

Zum Thema Datenbanken .. ich weis das z.b. Oracle amschnellsten auf RAW-Partitions ist da die ihr eigenes "Filesystem" haben.
Aber wie sichert man sowas? Oder wie bringt man da Verfügbarkeit? Raid 50?

 

[7oby]

Absolut korrekt: RAID0 macht sehr viel Sinn bei SSDs u. sehr selten für HDDs! Und übrigens versteh' ich nicht, warum sich irgendwelche Leute dazu hinreißen lassen einen seitenlang über MLC u. SLC Technologie aufklären zu wollen: Eine MLC intel X18/25 macht intern auch eine Art RAID0 indem sie selbstständig mehrere Flashseiten gleichzeitig lesen/schreiben kann. Ob MLC oder SLC drin ist entscheidet nicht unbedingt über die Performance sondern die Firmware und Implementierung. Die intel SSDs sind der beste Beweis.

Datenbanken zu backupen ist kein unlösbares Problem. Die Hersteller liefern dafür unterschiedliche Tools mit.

Wer mal ein bißchen Datenbank RAID schnuppern will für den hab' ich eine schöne kompakte Quelle:
http://blogs.zdnet.com/Ou/?p=484

Köstlich zu lesen, da ganz praxisnah so einige Mythen wie z.B. RAID10 = Performance aufgedeckt werden.

Ist mit Mainstream Host-Constroller (intel ICH9R). Und auch wer kein Bock auf Datenbank hat, kann dennoch so einiges aus dem Artikel herausziehen: Wenn man die Diagramme genau liest, dann erkennt man, dass der Intel RAID gleichzeitig von seinen RAID1 Teilnehmern liest. Und die Platte eines RAID1 Verbundes, die zuerst liefert, dessen Daten werden weitergegeben. Das ist eine Optimierung der Zugriffszeit (!!!). Und Zugriffszeit ist bei so Dingen wie Windows booten der Schlüssel. Also: Jedes intel RAID1 versägt ein RAID0 / RAID10 mit den gleichen Platten. Und auch im synthetischen HDTach Benchmark müsste die Accesstime sich reduzieren.

 

[H_M_Murdock]

Das mit den RAID 1 kann ich bestätigen.
Hab in meinem Server das OS am 3Ware 9550SXU auf 2x 74er WD Raptor die im RAID 1 hängen.

Seitdem das n RAID 1 ist isses schon nochmal nen Tick schneller geworden als vorher wo's nur ne einzelne HDD war.

 

[Rippi]

Ich verstehe den Sinn des Threads nicht. Klar du willst die Leute auf das Prob aufmerksam machen, aber irgendwie kommts mir grad so vor als wäre Raid0 das schlimmste was es gibt auf der Welt. Jetzt mal ehrlich, wer wirklich mit sehr wichtige Daten umgeht der wird sich wohl kaum ein Raid anschaffen, sondern die Daten extern auf nem Server oder ähnliches auslagern zumindest kenne ich das so von meiner Firma.....

 

[M.D. Geist]

Es gibt auch Raid1 Katastrophen!

Der Fall bezieht sich auf die Alte Firmware die inzwischen schon wieder kassiert wurde!!!
Kurioser Fall aus dem Seagate Support Forum. Der Kerl hatte 2
funktionstüchtige 500GB Platten im Raid (mit all seinen Daten aus den
letzten Jahren darauf), bekam von Seagate das Firmware Update Tool und hat
es laufen lassen, konnte aber nicht auswählen welche Platte geflasht werden
sollte, das Tool hat dann beide in den Tod geflasht!!! Beide Platten aus dem
Raid nicht mehr ansprechbar, Daten + Windows weg und der Rechner steht
still!!

Gruss
CPL

 

[Sukrim]

RAID1 erhöht ja auch nur die Datenverfügbarkeit, nicht die Datensicherheit!

Sowas zeigt das immer wieder recht hübsch - hoffentlich hat er Backups!

 

[M.D. Geist]

RAID1 erhöht ja auch nur die Datenverfügbarkeit, nicht die Datensicherheit!

wissen leider nich alle in diesem forum... raid5 wird auch oft überschätzt